JP6911865B2 - 協調計画システム、協調計画方法および協調計画プログラム - Google Patents

協調計画システム、協調計画方法および協調計画プログラム Download PDF

Info

Publication number
JP6911865B2
JP6911865B2 JP2018546161A JP2018546161A JP6911865B2 JP 6911865 B2 JP6911865 B2 JP 6911865B2 JP 2018546161 A JP2018546161 A JP 2018546161A JP 2018546161 A JP2018546161 A JP 2018546161A JP 6911865 B2 JP6911865 B2 JP 6911865B2
Authority
JP
Japan
Prior art keywords
procedure
planning
system configuration
state
unit
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2018546161A
Other languages
English (en)
Other versions
JPWO2018074042A1 (ja
Inventor
貴之 黒田
貴之 黒田
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NEC Corp
Original Assignee
NEC Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by NEC Corp filed Critical NEC Corp
Publication of JPWO2018074042A1 publication Critical patent/JPWO2018074042A1/ja
Application granted granted Critical
Publication of JP6911865B2 publication Critical patent/JP6911865B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G06Q10/101—Collaborative creation, e.g. joint development of products or services
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25—Integrating or interfacing systems involving database management systems
    • G06F16/258—Data format conversion from or to a database
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G06Q10/103—Workflow collaboration or project management

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Human Resources & Organizations (AREA)
  • Strategic Management (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Tourism & Hospitality (AREA)
  • Quality & Reliability (AREA)
  • Operations Research (AREA)
  • General Business, Economics & Management (AREA)
  • Marketing (AREA)
  • Economics (AREA)
  • Databases & Information Systems (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Stored Programmes (AREA)

Description

本発明は、協調計画システム、協調計画方法および協調計画プログラムに関する。
ICT(Information and Communication Technology) システムの構成が変更される際の事前の準備作業には、構成設計と手順計画が含まれる。構成設計は、変更により実現される、変更目的のシステム構成を設計する作業である。また、手順計画は、設計された変更目的のシステム構成を実現するための変更作業を計画する作業である。
手順計画では、状況に応じて様々な要件を考慮することが求められる。例えば、全ての作業が正常に実行されるためには、変更対象のシステムを構成する部品間の依存関係が踏まえられることが求められる。また、システムが重要なサービスを提供している場合、変更作業中にサービスが安定的に提供され続けるための条件も考慮されることが求められる。
従って、大規模で複雑なシステムの構成変更に関する変更作業が計画されると、変更作業の難度の高さや変更作業に掛かる工数の大きさが問題になる。よって、難度が高くなりすぎないという要件や、工数が大きくなりすぎないという要件が考慮されることが求められる。
特許文献１〜特許文献３、および非特許文献１には、上記の問題を解決できる計画システムが記載されている。計画システムを使用する場合、利用者は、変更目的のシステム構成の定義を計画システムに入力するだけで、構成変更が実現される変更手順を生成できる。
計画システムが使用される手法では、一連の変更手順を構成する様々な個々の作業の情報が定義される。また、部品間の依存関係や他の要件事項が汎用的な制約条件として規定される。さらに、変更対象のシステムの構成が、システム構成定義として管理される。
計画システムは、上記の情報を用いて、変更目的の構成を示すシステム構成定義と現在の構成を示すシステム構成定義との差分から、変更に要する作業を抽出する。次いで、計画システムは、制約条件を踏まえて抽出された作業を適切な順序に並べることによって、変更手順を自動的に生成する。
計画システムが使用される手法では計画システムが手順計画を実行するため、より容易なシステム構成の変更作業が生成されることと、手順計画に掛かる工数が削減されることが、計画システムが使用される手法の利点である。
また、単にシステムを自動的に制御するツールと異なり、計画システムが使用されると変更作業が実行される前に作業手順が明示される。すなわち、変更作業が及ぼす影響を事前に利用者が確認、合意、および納得でき、安心して変更作業を実行できる点も計画システムが使用される手法の重要な利点である。
例えば、仮想マシン（以下、VM(Virtual Machine) ともいう。）において稼働するサービスがVMに依存するという制約が定義されている場合、VMの停止が要求された時に生成される作業手順には、サービスの停止作業が含まれる。よって、利用者は、VMを停止する場合にサービスが停止されることを、VMの停止作業を実行する前に認識できる。
計画システムが大規模なシステムの構成変更の変更作業を生成すれば、利用者は、生成された変更作業に基づいて一部の変更が原因で生じる他の変更を広範囲に渡って機械的に追跡できる。すなわち、利用者は、手動では確認が困難な変更作業が及ぼす影響を事前に検証できる。
特開２０１５−２１５８８５号公報 特開２０１５−２１５８８６号公報 特開２０１５−２１５８８７号公報
T. Kuroda and A. Gokhale, "Model-based it change managementfor large system definitions with state-related dependencies," in Enterprise Distributed Object Computing Conference(EDOC), 2014 IEEE 18th International, Sept 2014, pp. 170-179.
しかし、一般的な計画システムが使用される場合、手順計画処理の仕組みが原因で生じる制約によって変更対象のシステムの構成定義が一箇所で管理されていることが求められるため、上記の利点が充分に享受されない。
一般的に多くのシステムは、異なる組織により運用される外部のシステムと依存関係を有する。すなわち、多くのシステムは、外部のシステムに影響を及ぼしたり、外部のシステムから影響が及ぼされたりしながら成立している。
例えば、B 社が提供する基盤においてA 社のシステムが運用されている場合、A 社のシステムの拡張作業は、B 社の基盤に関する余剰計算資源量に影響を及ぼす。また、B 社の基盤におけるメンテナンス作業は、A 社のシステムの稼働状況に影響を及ぼす。
また、X 社とY 社が共同でシステムを運用し、Y 社のモジュールが提供する機能をX 社のモジュールが利用している場合、Y 社のモジュールを含むシステムの構成変更作業は、X 社のモジュールの動作に影響を及ぼす。
上記の各状況において手動で変更作業が計画された場合、複雑な変更作業が計画されることが考えられる。複雑な変更作業が計画されると、変更作業が及ぼす影響の調査や様々な調整が行われるための組織間の連携作業が多く発生する可能性がある。影響の調査や組織間の連携作業を少しでも抑えるために、より簡易な変更作業を計画できる計画システムを活用することが期待される。
しかし、異なる組織の各システム構成を一元的に管理することは、各組織の運用政策面で問題になることが多い。すなわち、異なる組織の各システム構成を一元的に管理することが困難なことが、計画システムが活用される上での制約になる。
上述したように、複数の管理ドメインそれぞれで管理されるシステムが影響する場合において、複数の管理ドメインに影響を及ぼす一連のシステム構成の変更作業が各システムの協調動作により実現されるためのシステム構成の変更手順の生成方法が求められている。しかし、異なる組織の各システム構成を一元的に管理した上でシステム構成の変更手順を生成することは困難である。
また、上記の理由により、全体を把握している構成要素が存在しない場合であってもシステム構成の変更手順が生成されることが好ましい。特許文献１〜特許文献３、および非特許文献１には、上記の問題に関する取り組みが記載されていない。
［発明の目的］
そこで、本発明は、上述した課題を解決する、複数の管理ドメインに影響を及ぼすシステムの構成変更の手順を各管理ドメイン内で生成される部分的な手順の集合として生成できる協調計画システム、協調計画方法および協調計画プログラムを提供することを目的とする。
本発明による協調計画システムは、システム構成をそれぞれ管理する複数の計画システムと、複数のシステム構成の変更要求に対する変更手順を生成する生成部とを含む協調計画システムであって、生成部は、複数の計画システムから入力された複数のシステム構成の定義を基に変更手順を生成し、生成された変更手順を各システム構成の要素に関する手順ごとに分割することによって複数の部分的な手順を生成し、実行が完了すると第２の部分的な手順に含まれる第２の手順の実行が開始される第１の手順を含む第１の部分的な手順に対して第２の部分的な手順を実行する計画システムに手順の完了を示す情報を入力する手順を第１の手順の後に追加し、第２の部分的な手順に対して第１の部分的な手順を実行する計画システムから手順の完了を示す情報が入力される手順を第２の手順の前に追加することを特徴とする。
本発明による協調計画方法は、システム構成をそれぞれ管理する複数の計画システムを含み、複数のシステム構成の変更要求に対する変更手順を生成する協調計画システムにおいて実行される協調計画方法であって、複数の計画システムから入力された複数のシステム構成の定義を基に変更手順を生成し、生成された変更手順を各システム構成の要素に関する手順ごとに分割することによって複数の部分的な手順を生成し、実行が完了すると第２の部分的な手順に含まれる第２の手順の実行が開始される第１の手順を含む第１の部分的な手順に対して第２の部分的な手順を実行する計画システムに手順の完了を示す情報を入力する手順を第１の手順の後に追加し、第２の部分的な手順に対して第１の部分的な手順を実行する計画システムから手順の完了を示す情報が入力される手順を第２の手順の前に追加することを特徴とする。
本発明による協調計画プログラムは、システム構成をそれぞれ管理する複数の計画システムを含み、複数のシステム構成の変更要求に対する変更手順を生成するコンピュータにおいて実行される協調計画プログラムであって、コンピュータに、複数の計画システムから入力された複数のシステム構成の定義を基に変更手順を生成する第１生成処理、生成された変更手順を各システム構成の要素に関する手順ごとに分割することによって複数の部分的な手順を生成する第２生成処理、実行が完了すると第２の部分的な手順に含まれる第２の手順の実行が開始される第１の手順を含む第１の部分的な手順に対して第２の部分的な手順を実行する計画システムに手順の完了を示す情報を入力する手順を第１の手順の後に追加する第１追加処理、および第２の部分的な手順に対して第１の部分的な手順を実行する計画システムから手順の完了を示す情報が入力される手順を第２の手順の前に追加する第２追加処理を実行させることを特徴とする。
本発明によれば、複数の管理ドメインに影響を及ぼすシステムの構成変更の手順を各管理ドメイン内で生成される部分的な手順の集合として生成できる。
本発明による計画システムの第１の実施形態の構成例を示すブロック図である。 複数の計画システムで構成されるシステムの構成例を示す説明図である。 システム構成定義の一例を示す説明図である。 システム構成の変更要求の一例を示す説明図である。 第１の実施形態で生成されるシステム構成の変更手順の一例を示す説明図である。 第１の実施形態の計画システム１００による変更手順の生成処理の全体動作を示すフローチャートである。 第１の実施形態の計画システム１００による変更手順の生成処理の具体例を示す説明図である。 深さ優先探索処理の一例を示す説明図である。 第１の実施形態の調整部１０３による影響範囲抽出処理の動作を示すフローチャートである。 影響範囲抽出処理中の管理ドメインごとの記録情報の一例を示す説明図である。 強連結成分への分解処理の一例を示す説明図である。 第１の実施形態の調整部１０３によるグループ分割処理の全体動作を示すフローチャートである。 第１の実施形態の調整部１０３による順方向の深さ優先探索処理の動作を示すフローチャートである。 グループ分割に用いられる番号が付与された状態要素の一例を示す説明図である。 番号付与処理中の管理ドメインごとの記録情報の一例を示す説明図である。 番号付与の処理において協調部間で送受信される通信内容の一例を示す説明図である。 第１の実施形態の調整部１０３による逆方向の深さ優先探索処理の動作を示すフローチャートである。 グループ分割に用いられる番号が付与された状態要素の他の一例を示す説明図である。 強連結成分分解処理中の管理ドメインごとの記録情報の一例を示す説明図である。 強連結成分分解の処理において協調部間で送受信される通信内容の一例を示す説明図である。 ステップS1400 のグループ分割処理により生成されるグループの一例を示す説明図である。 第１の実施形態の計画部１０２によるプランニングの全体動作を示すフローチャートである。 第１の実施形態の計画部１０２による手順生成処理の動作を示すフローチャートである。 協調部と結合部との間で送受信される通信内容の一例を示す説明図である。 第１の実施形態の結合部１２０による手順探索処理の動作を示すフローチャートである。 協調部と結合部との間で送受信される通信内容の他の一例を示す説明図である。 結合部１２０内に記録される情報の一例を示す説明図である。 結合部１２０が生成するシステム構成の変更手順の一例を示す説明図である。 結合部１２０が生成するシステム構成の変更手順の他の一例を示す説明図である。 管理ドメインごとの匿名情報の一例を示す説明図である。 本発明による計画システムの第２の実施形態の構成例を示すブロック図である。 一般的な高級なシステム構成定義の一例を示す説明図である。 高級なシステム構成定義がコンパイルされた低級なシステム構成定義の一例を示す説明図である。 第２の実施形態の高級なシステム構成定義の一例を示す説明図である。 第２の実施形態の高級なシステム構成定義の他の一例を示す説明図である。 第２の実施形態の高級なシステム構成定義がコンパイルされた低級なシステム構成定義の一例を示す説明図である。 第２の実施形態の高級なシステム構成定義がコンパイルされた低級なシステム構成定義の他の一例を示す説明図である。 第２の実施形態のシステム構成の低級な変更要求定義の一例を示す説明図である。 第２の実施形態の計画システム１００ａによる高級なシステム構成定義のコンパイル処理の具体例を示す説明図である。 第２の実施形態の計画システム１００ａによる高級なシステム構成定義のコンパイル処理の動作を示すフローチャートである。 コンパイル処理の開始の要求時および返答時に送受信される通信内容の一例を示す説明図である。 管理フィールドの探索の要求時および返答時に送受信される通信内容の一例を示す説明図である。 管理フィールドの探索中の管理ドメインごとの記録情報の一例を示す説明図である。 管理フィールドの探索中の管理ドメインごとの記録情報の他の一例を示す説明図である。 管理フィールドの情報が通知された後の管理ドメインごとの記録情報の一例を示す説明図である。 関係性の収集の要求時および返答時に送受信される通信内容の一例を示す説明図である。 管理ドメインごとに関係性がまとめられた記録情報の一例を示す説明図である。 管理フィールドの探索の要求時および返答時に送受信される通信内容の他の一例を示す説明図である。 関係性の収集の要求時および返答時に送受信される通信内容の他の一例を示す説明図である。 協調部と結合部との間で送受信される通信内容の他の一例を示す説明図である。 本発明による協調計画システムの概要を示すブロック図である。
（第１の実施の形態）
［構成の説明］
以下、本発明の実施形態を、図面を参照して説明する。図１は、本発明による計画システムの第１の実施形態の構成例を示すブロック図である。図１に示すように、本実施形態の計画システム１００は、協調部１０１と、計画部１０２と、調整部１０３とを含む。
図１に示すように、協調部１０１は、計画部１０２および調整部１０３と、通信ネットワーク等を介して通信可能に接続されている。また、計画部１０２は、調整部１０３および計画システム１００の外部の入出力装置２００と通信ネットワーク等を介して通信可能に接続されている。
また、図１に示すように、協調部１０１は、他の計画システム１１０や計画システム１００の外部の結合部１２０と通信ネットワーク等を介して通信可能に接続されている。また、他の計画システム１１０は、協調部１０１が通信可能に接続されている同一の結合部１２０と通信ネットワーク等を介して通信可能に接続されている。また、計画システム１００の各構成要素は、記憶装置３００および制御装置４００と通信ネットワーク等を介して通信可能に接続されている。
協調部１０１は、計画システム１００の外部の要素との協調動作を実行する機能を有する。協調部１０１は、計画部１０２や調整部１０３からの依頼に基づいて、通信可能な任意の他の計画システム１１０、および結合部１２０との協調動作を実行する。
計画部１０２は、システム構成の変更手順を生成する機能を有する。計画部１０２は、利用者が入力したシステム構成の変更要求を受け付け、要求されたシステム構成の変更を実現可能なシステム構成の変更手順を生成する。また、計画部１０２は、利用者に生成された変更手順を返答する。
調整部１０３は、システム構成定義を調整する機能を有する。調整部１０３は、記憶装置３００から読み込んだシステム構成定義を調整し、調整されたシステム構成定義を計画部１０２に入力する。
記憶装置３００には、計画システム１００が管理するシステム構成定義が記憶されている。また、記憶装置３００には、情報が記録されるための記憶領域が生成される。なお、記憶領域が生成される場所は、記憶装置３００に限定されない。
制御装置４００は、計画部１０２が生成したシステム構成の変更手順に従ってシステム構成の変更処理を実行する機能を有する。
複数の図１に示す計画システム１００で構成されるシステムの例を図２に示す。図２は、複数の計画システムで構成されるシステムの構成例を示す説明図である。
各計画システムは、それぞれの結合部（図示せず）を介して他の計画システムと通信可能に接続されている。また、各計画システムの記憶装置３００には、システム構成定義が記憶されている。
図２に示す計画システムが管理するシステム構成定義は、他の計画システムが管理するシステム構成定義と関連している。具体的には、図２に示す点線の矢印は、システム構成定義間の関係性を表現している。以下、計画システムにより管理されるシステム構成定義の範囲を、計画システムの管理ドメインと呼ぶ。
本実施形態のシステム構成定義は、状態要素と呼ばれる構成要素の集合で表現される。状態要素には、自身が取り得る状態や、実行可能な状態遷移を示す各情報が含まれる。また、状態要素には、自身の現在状態、自身の目的状態、および他の状態要素との関係性を示す各情報が適宜含まれる。
図２に示すシステム構成定義内の実線の矩形が状態要素を表す。矩形の左上の文字が状態要素の名称である。また、状態要素内の楕円が、状態要素の取り得る状態を表す。楕円内の文字が状態の名称である。また、状態間の矢印が状態遷移を表す。また、破線の楕円は現在状態を、黒色の楕円は目的状態をそれぞれ表す。また、状態遷移と他の状態要素内の状態とを結ぶ点線の矢印が、他の状態要素との関係性を表す。
図３は、システム構成定義の一例を示す説明図である。図３に示すシステム構成定義は、図２に示す管理ドメインD2内のシステム構成定義である。
図３に示す例では、情報の表現形式としてJSON(JavaScript(登録商標) Object Notation)形式が用いられている。以下、本明細書ではテキスト形式で情報を表現する場合、表現形式にJSON形式を用いる。なお、システム構成定義は、JSON形式以外の表現形式で表現されてもよい。
図３には、状態要素として"e1"と"e2"が記載されている。図３に示すように、状態要素"e1"は、取り得る状態として"s1"と"s2"を持つ。また、状態要素"e1"は、実行可能な状態遷移として"s1 からs2への遷移" （図３に示す"s1->s2"）と、逆向きの遷移である"s2 からs1への遷移" （図３に示す"s2->s1"）をそれぞれ持つ。
また、図３に示すように、状態要素"e1"の現在状態および目的状態は、共に状態"s2"である。また、状態要素"e1"は、他の状態要素との関係性を示す情報として、２つの事前状態制約を持つ。
本実施形態の事前状態制約は、システム構成定義間の関係性を示す情報の例である。事前状態制約は、状態遷移が実行されるためには別の状態要素が所定の状態であることを要するという制約である。事前状態制約が用いられると、例えば、仮想マシン(VM)において稼働するサービスがある場合、サービスの状態を" 稼働状態" に遷移させるためにはVMの状態が" 稼働状態" であることを要するという関係性が表現される。
特許文献２に記載されている手法は、１つ以上の状態要素の現在状態と目的状態が異なる場合、事前状態制約を満たしつつ全ての状態要素の状態を現在状態から目的状態へと遷移させるシステム構成の変更手順を生成できる。上記のVMとサービスの例では、最初にVMを起動し、続いてサービスを起動するという順序性を持つシステム構成の変更手順が生成される。
また、本実施形態のシステム構成定義では、他の管理ドメイン内のシステム構成定義に含まれる状態要素に対しても関係性が指定される。図３に示す例では、状態要素"e1"の状態遷移"s1->s2"は、管理ドメインDN内の状態要素"e1"の状態"s1"に対して事前状態制約を指定している。また、状態要素"e1"の状態遷移"s2->s1"は、同じ管理ドメインD2内の状態要素"e2"の状態"s1"に対して事前状態制約を指定している。
なお、他の管理ドメイン内の状態要素は、図３に示す"DN::e1"のように、管理ドメインを示すidが付与されることによって表現されてもよい。以下、本明細書では管理ドメイン内の情報を表現する場合、管理ドメイン内の情報と管理ドメインを示すidを"::"で繋ぐ記載方法を用いる。
なお、動作の都合上、本実施形態のシステム構成定義間の関係性を示す情報は、各システム構成定義内の両方の状態要素に保持される。例えば、事前状態制約が指定されている側の状態要素には、図３に示すように指定された事前状態制約が" 被事前状態制約" として記録される。
図４は、システム構成の変更要求の一例を示す説明図である。図４に示すように、管理ドメインにおいて受け付けられるシステム構成の変更要求には、管理ドメイン内の状態要素の新たな目的状態が指定される。
例えば、所定の時点におけるシステム構成定義が図２に示す内容であり、管理ドメインD1において図４に示すシステム構成の変更要求が受け付けられた場合を考える。図２に示すように、状態要素"D1::e1"の現在状態は状態"s1"である。図４に示すシステム構成の変更要求では目的状態が状態"s2"に指定されているため、状態要素"D1::e1"には、状態"s2"に遷移することが求められる。
図３を参照すると、状態要素"D1::e1"が状態"s2"に遷移する場合、事前状態制約が満たされることが条件になる。具体的には、状態要素"D2::e1"に状態"s1"に遷移することが求められる。さらに、状態要素"D2::e1"が状態"s1"に遷移するために、状態要素"D2::e2"に状態"s1"に遷移することが求められる。
また、図２に示すように状態要素"D2::e1"の目的状態が状態"s2"であるため、状態要素"D2::e1"には、状態"s1"に遷移した後で再度状態"s2"に遷移することが求められる。なお、状態要素"D2::e2"には目的状態が指定されていないため、状態要素"D2::e2"は、状態"s1"に遷移した後に他の状態に遷移しなくてよい。
なお、図３を参照すると、状態要素"D2::e1"から状態要素"DN::e1"の状態"s1"に事前状態制約が指定されている。しかし、図２に示すように、状態要素"DN::e1"の現在状態が状態"s1"であるため、図４に示す変更要求に関して状態要素"DN::e1"に事前状態制約の影響は及ばないと考えられる。
本実施形態では、例えば図５に示すシステム構成の変更手順が生成される。図５は、第１の実施形態で生成されるシステム構成の変更手順の一例を示す説明図である。
図５に示すシステム構成の変更手順には、図５（ａ）に示す管理ドメインD1における変更手順と、図５（ｂ）に示す管理ドメインD2における変更手順が含まれる。すなわち、本実施形態で生成される変更手順は、管理ドメインごとに分けて表現される。
また、本実施形態で生成される変更手順には、作業が行われる管理ドメインが変更される際に作業を開始させるための手順が加えられている。図５（ｂ）に示す"call X"は、一連の作業におけるポイント"X" まで作業が完了したことを管理ドメインD1内の計画システムに通知する手順である。ポイント"X" まで作業が完了した後、"call X"が実行される。図５（ａ）に示す"call Y"も"call X"と同様の手順である。
また、図５（ａ）に示す"wait X"は、管理ドメインD1内の計画システムがポイント"X" まで作業が完了したことの通知を待ち受ける手順である。"wait X"が実行された後、ポイント"X" 以降の作業が実行される。図５（ｂ）に示す"wait Y"も"wait X"と同様の手順である。
すなわち、図５は、最初に状態要素"D2::e2"を状態"s2"から状態"s1"へ遷移させ、次いで状態要素"D2::e1"を状態"s2"から状態"s1"へ遷移させ、次いで状態要素"D1::e1"を状態"s1"から状態"s2"へ遷移させ、最後に状態要素"D1::e1"を状態"s1"から状態"s2"へ再度遷移させるという一連の手順を示す。
図５に示すようなシステム構成の変更手順が各管理ドメイン内に用意されれば、各計画システムが担当するシステム構成の変更手順を実行することによって、全体的に整合が保たれたまま、一連のシステム構成の変更作業が実行される。
図５に示すシステム構成の変更手順は、以下に説明する概念に基づいて生成される。例えば、異なる２つの管理ドメインDAおよび管理ドメインDBと、管理ドメインDAで管理されるシステムSA、および管理ドメインDBで管理されるシステムSBを想定する。システムSAは、システムSBとの間に依存関係を有する。
システムSAに対するシステム構成の変更要求の影響がシステムSBに及ぶ場合を考える。上記の場合、システムSAに関するシステム構成の変更手順PAは、管理ドメインDA内でのみ生成されれば充分であると考えられる。同様に、システムSBに関するシステム構成の変更手順PBは、管理ドメインDB内でのみ生成されれば充分であると考えられる。
さらに、各管理ドメインにおいて変更手順の内容が承認された上で、システムSAとシステムSBが協調的に動作することによって全ての作業が完遂されればよいと考えられる。本実施形態では、上記の概念に基づいてシステム構成の変更手順が生成される。
なお、システム構成の変更手順を生成する際、本実施形態の計画システム１００は、状態要素自体を管理ドメイン間で交換しない。状態要素群を一箇所に集めることが避けられない手順探索処理を実行する場合、計画システム１００は、外部の結合部１２０を用いる。その理由は、他の計画システム１１０に開示される状態要素の内容を最低限にするためである。また、結合部１２０に集められる状態要素群の数を最小限に留めるために、計画システム１００は、グループ分割等の前処理を実行する。
［動作の説明］
以下、本実施形態の計画システム１００の動作を図６、図９、図１２、および図２２を参照して説明する。図６は、第１の実施形態の計画システム１００による変更手順の生成処理の全体動作を示すフローチャートである。
本実施形態の計画システム１００が実行する変更手順の生成処理では、複数の管理ドメイン内のシステム構成定義が処理の対象になる。計画システム１００は、他の管理ドメイン内の計画システム群と協調して処理を進める。
計画部１０２は、入出力装置２００を介して利用者からシステム構成の変更要求を受け付ける。受け付けた後、計画部１０２は、システム構成の変更要求が一意に特定される変更要求idを生成する（ステップS1100 ）。
次いで、計画部１０２は、受け付けられたシステム構成の変更要求に関する情報を生成された変更要求idと対応付けて記録するための記憶領域を記憶装置３００に生成する（ステップS1200 ）。計画部１０２は、生成された記憶領域にシステム構成の変更要求に関する情報を変更要求idと対応付けて記録する。
次いで、計画部１０２は、ステップS1100 で生成された変更要求idを調整部１０３に通知する。以下、システム構成の変更要求に関する情報は、常に変更要求idと共に記憶領域に記録される。変更要求に関する情報が参照される際、変更要求idが参照キーになる。
変更要求idが通知された後、調整部１０３は、記憶装置３００からシステム構成定義を読み込む。次いで、調整部１０３は、読み込まれたシステム構成定義における通知された変更要求idが示す変更要求の影響範囲を抽出する（ステップS1300 ）。
各計画システムが管理するシステム構成定義は、多くの状態要素群で構成されている可能性がある。すなわち、システム構成定義全体が考慮の対象になると、手順計画の実行が困難になる恐れがある。本実施形態では、調整部１０３が影響範囲を抽出することによって、システム構成の変更に関係する部分だけを基に変更手順が生成される。
例えば、管理ドメインD1内の計画システムが図４に示すシステム構成の変更要求を受け付けた上記の例の場合、調整部１０３は、図２に示す状態要素"DN::e1"が影響範囲外の状態要素であると判断し、状態要素"DN::e1"を影響範囲に含めない。
次いで、調整部１０３は、システム構成定義から抽出された影響範囲を、計画部１０２による手順探索処理が一括で行われるグループごとに分割する（ステップS1400 ）。調整部１０３は、生成された複数のグループを計画部１０２に入力する。
手順探索処理には、一度に処理される状態要素が増えると加速度的に処理負荷が高くなるという問題がある。また、複数の管理ドメイン内のシステム構成定義に対する手順探索処理が実行されるためには、システム構成定義が一箇所に集められることが求められる。よって、集められるシステム構成定義の範囲を最小化することがセキュリティ上重要である。
具体的な分割方法として、例えば特許文献３に記載されている手法と同様にシステム構成定義を、システム構成定義内の状態要素がノード、状態要素間の関係性がエッジであるグラフと捉えた上で、グラフを強連結成分ごとに分割する方法がある。
次いで、計画部１０２は、入力された全てのグループに対して手順探索処理を実行する。計画部１０２は、手順探索処理の実行結果として生成される部分的な手順を繋ぎ合わせることによって、システム構成の変更手順全体を生成する（ステップS1500 ）。なお、図６に示すように、ステップS1500 の処理全体をプランニングと呼ぶ。システム構成の変更手順を生成した後、計画システム１００は、変更手順の生成処理を終了する。
図７は、第１の実施形態の計画システム１００による変更手順の生成処理の具体例を示す説明図である。図７に示す矩形は状態要素を表し、点線の矢印は事前状態制約を表している。矩形内の文字が状態要素の名称である。
以下、変更手順の生成処理を構成する副処理である、ステップS1300 の影響範囲抽出処理、ステップS1400 のグループ分割処理、およびステップS1500 のプランニングを図７を参照してそれぞれ説明する。
以降の説明を簡略化するために、各副処理で多用される一般的な深さ優先探索処理を説明する。深さ優先探索処理は、ノードとエッジで構成されたグラフが与えられグラフ内の１つのノードが指定された時に、指定されたノードを起点として到達可能な全てのノードを発見する処理の１つである。深さ優先探索処理では、新たに発見された到達可能なノードから更に到達可能な他のノードが優先的に探索される。
図８は、深さ優先探索処理の一例を示す説明図である。図８に示す円はノードを表す。円内の文字がノードの名称である。また、図８に示すノード同士を結ぶ矢印は、エッジを表す。
図８（ａ）は、ツリーにおける深さ優先探索処理を示す。図８（ａ）に示すツリー、およびノード"a" が指定された場合、深さ優先探索処理では、最初にノード"a" から到達可能なノード"b" が発見される。次いで、ノード"b" から更に到達可能なノード"d" が発見される。
図８（ａ）に示すようにノード"d" から更に到達可能なノードは存在しないため、ノード"d" が発見された後、ノード"b" から到達可能な別のノードであるノード"e" が発見される。ノード"e" から更に到達可能なノードは存在せず、またノード"b" から到達可能な別のノードも残っていないため、ノード"e" が発見された後、ノード"a" から到達可能な別のノードであるノード"c" が最後に発見される。
図８（ａ）に示す点線の矢印は、上記の基本的な深さ優先探索の軌跡を示す。なお、深さ優先探索処理の対象は、図８（ａ）に示すようなツリー以外の一般的なグラフでもよい。ただし、一度発見されたノードは探索の対象から外されるため、探索結果だけが着目されると、深さ優先探索処理では常にツリーが構成される。
図８（ｂ）は、グラフにおける深さ優先探索処理を示す。図８（ｂ）に示すグラフにおいて、ノード"d" の次にノード"b" が探索されようとしても、既にノード"b" は発見されているため、結果的に探索されない。
深さ優先探索処理が複数の管理ドメインに渡って行われる場合、探索の開始時に探索作業が一意に特定される探索idが生成される。ノードが発見された際、生成された探索idが示す探索作業においてノードが既に発見されているか否かが確認される。
管理ドメインを跨るエッジが辿られる際、探索元の管理ドメイン内の計画システムは、探索idの下でどのノードからどのノードに向けて探索が進められるかを探索先の管理ドメイン内の計画システムに通知すればよい。
また、管理ドメインを跨るエッジが逆方向に辿られる際、探索先の管理ドメイン内の計画システムは、探索idの下でどのノードからどのノードに向けて探索が戻されるかを探索元の管理ドメイン内の計画システムに通知すればよい。
また、管理ドメイン内のノードから他の管理ドメイン内のノードに向けて探索が進められようとした際に探索先のノードが既に探索済みであった場合、探索先の管理ドメイン内の計画システムは、ノードが探索済みである旨を単に返答すればよい。
図８（ｃ）は、管理ドメインを跨るグラフにおける深さ優先探索処理を示す。図８（ｃ）に示す例において、例えばノード"a,b,d" が探索された後にノード"d" からノード"b" に向けて探索を進めようとする際、管理ドメインD2内の計画システムは、管理ドメインD1内の計画システムに対して探索を依頼する。
探索を依頼された管理ドメインD1内の計画システムは、ノード"b" が探索済みであることを管理ドメインD2内の計画システムに返答する。返答を受けた管理ドメインD2内の計画システムは、ノード"f" に向けてさらに探索を進めればよい。
以下の副処理の説明では、深さ優先探索が用いられる場合であっても上述した基本的な動作の説明を省略する。副処理の説明の中で、処理の種類に応じる箇所を説明することによって深さ優先探索処理の内容を示す。
処理の種類に応じる箇所は、例えばノードとみなされる対象、およびエッジとみなされる対象である。また、処理の種類に応じる箇所は、ノードが最初に発見された時に実行される処理や、ノードから探索可能な他のノードが全て発見されて探索が戻される際に実行される処理である。
また、処理の種類に応じる箇所は、管理ドメインを跨いで探索が進められる際に管理ドメイン内の計画システム間で送受信される通信内容や、送受信の前後に実行される処理等である。
最初に、ステップS1300 の影響範囲抽出処理を図９を参照して説明する。図９は、第１の実施形態の調整部１０３による影響範囲抽出処理の動作を示すフローチャートである。
影響範囲抽出処理において、調整部１０３は、変更を要する状態要素を起点に、状態要素との関係性に従って付随的に変更される状態要素や、付随的に変更される状態要素を起因として連鎖的に変更される全ての状態要素を発見する。
変更される全ての状態要素を発見するために、調整部１０３は、図９に示す影響範囲抽出処理を行う。システム構成の変更要求が受け付けられた管理ドメイン内の調整部１０３は、システム構成の変更要求で目的状態が指定された状態要素のうち、指定された目的状態が記憶装置３００に記録された現在状態と異なる状態要素を、変更を要する状態要素とみなす（ステップS1310 ）。次いで、調整部１０３は、変更を要する状態要素が影響範囲に含まれることを記録する。
次いで、調整部１０３は、ステップS1310 で発見された状態要素の変更が影響する他の状態要素を探索する。調整部１０３は、ステップS1310 で発見された各状態要素のうち、変更が影響する他の状態要素が未探索の状態要素が残っているか否かを確認する（ステップS1320 ）。
未探索の状態要素が残っていない場合（ステップS1320 におけるYes ）、調整部１０３は、影響範囲抽出処理を終了する。
未探索の状態要素が残っている場合（ステップS1320 におけるNo）、調整部１０３は、未探索の状態要素を１つ取り出す。次いで、調整部１０３は、取り出された状態要素を起点とした深さ優先探索処理を実行することによって、変更が影響する他の状態要素を発見する（ステップS1330 ）。
ステップS1330 で実行される深さ優先探索処理では、状態要素がノードとみなされる。また、ノードである状態要素が有する関係性が他の状態要素に影響を及ぼす可能性がある場合、関係性がエッジとみなされる。
状態要素が有する関係性が事前状態制約であれば、関係性は、指定された状態要素の状態が状態要素の現在状態と異なる場合に影響を及ぼす可能性があると判断される。その理由は、上述したような事前状態制約は、状態遷移が実行されるために指定された状態要素が現在状態と異なる状態に遷移することを要すると示すためである。
また、ステップS1330 で実行される深さ優先探索処理においてノードが発見された際、調整部１０３は、発見されたノードに相当する状態要素を、ノードが存在する管理ドメインにおける影響範囲に追加する。深さ優先探索処理を終了した後、調整部１０３は、再度ステップS1320 の処理を行う。
例えば、図７（ａ）に示すシステム構成定義から影響範囲を抽出する処理を考える。管理ドメインD1内の計画システム１００がシステム構成の変更要求を受け付けた後、状態要素"a" 、状態要素"h" 、および状態要素"x" の変更が確定されたとする。なお、図７に示す黒色の状態要素は、変更が確定された状態要素である。
調整部１０３は、状態要素"a" を起点とした深さ優先探索処理を実行することによって、変更が影響する状態要素として例えば状態要素"a,b,c,d,e,f,g,h,i" を発見する。深さ優先探索処理が実行された段階で、未探索の状態要素である状態要素"x" が残っている。
次いで、調整部１０３は、状態要素"x" を起点とした深さ優先探索処理を実行することによって、変更が影響する状態要素として状態要素"x,y" を発見する。２回目の深さ優先探索処理が実行された段階で未探索の状態要素は残っていないため、調整部１０３は、影響範囲抽出処理を終了する。図７（ｂ）に示す実線の枠が、最終的に抽出された影響範囲を表す。
図１０は、影響範囲抽出処理中の管理ドメインごとの記録情報の一例を示す説明図である。図１０は、管理ドメインD2における影響範囲の記録情報の例を示す。図１０に示すように、影響範囲に含まれる状態要素として、状態要素"b,f,g,y" が記録されている。影響範囲に含まれる状態要素は、状態要素が存在する各管理ドメインにおいて記録されていればよい。
次に、ステップS1400 のグループ分割処理を説明する。上記の通り、グループ分割処理ではシステム構成定義が、システム構成定義内の状態要素がノード、状態要素間の関係性がエッジであるグラフと捉えられる。グループ分割処理において、調整部１０３は、グラフを複数の強連結成分に分解する。
強連結成分の分解方法は、複数存在する。本実施形態では、複数の方法のうちの１つの方法が用いられた処理例を示す。以下、本実施形態で用いられる強連結成分の分解方法を説明する。なお、本実施形態で用いられる強連結成分の分解方法は、以下に示す方法に限定されない。
図１１は、強連結成分への分解処理の一例を示す説明図である。図１１に示す円はノードを表す。円内の文字がノードの名称である。また、図１１に示すノード同士を結ぶ矢印は、エッジを表す。図１１に示す手法によれば、深さ優先探索処理が２回実行されることによって、グラフ全体が複数の強連結成分に分解される。
１回目の深さ優先探索処理では、適当なノードから探索が実行され、探索が開始されたノードからの探索ステップが最も深いノードから順に番号が付与される。例えば、図１１（ａ）に示すグラフが与えられ、ノード"a" が探索の開始ノードに選択されたとする。
１回目の深さ優先探索処理で"a","b","d","e","f" の順にノードが辿られた後、ノード"f" の先にノードは発見されない。よって、ノード"f" に番号「1 」が付与される。次いで、ノード"g" の先にノードは発見されないため、ノード"g" に番号「2 」が付与される。
次いでノード"e" に探索が戻された後、ノード"e" の先にノード"f,g" 以外の新たなノードは発見されないため、ノード"e" に番号「3 」が付与される。以下、同様に処理が進められると、図１１（ｂ）に示すように各ノードに番号が付与される。図１１に示すノードの近傍の数字が、ノードに付与された番号である。なお、図１１（ｂ）に示す点線の矢印は、探索の軌跡を表す。
次に、２回目の深さ優先探索処理では、エッジの向きが逆向きに変更された上で、付与された番号が最大のノードから探索が開始される。探索された際に到達可能なノード群が１つの強連結成分を形成する。
例えば、最大の番号である番号「7 」が付与されたノード"a" から探索を開始すると、エッジの向きが逆になったことに注意すれば、調整部１０３は、"a,c,b" の３つのノードがノード"a" から到達可能なノードであることが分かる。すなわち、図１１（ｃ）に示すように、ノード群"a,c,b" は、強連結成分を形成する。図１１に示す破線の楕円が、強連結成分を表す。
次いで、強連結成分を形成すると判定されたノードが除外された上で、現時点で最大の番号である番号「4 」が付与されたノード"d" から探索を再度開始すると、調整部１０３は、"d,e" の２つのノードがノード"d" から到達可能なノードであることが分かる。すなわち、図１１（ｄ）に示すように、ノード群"d,e" は、強連結成分を形成する。同様に、ノード"f" のみで形成された強連結成分と、ノード"g" のみで形成された強連結成分が発見される。
ステップS1400 のグループ分割処理では、複数の管理ドメイン内の計画システムが、上述したような強連結成分への分解処理を協調して実行する。以下、ステップS1400 のグループ分割処理の動作を説明する。図１２は、第１の実施形態の調整部１０３によるグループ分割処理の全体動作を示すフローチャートである。
調整部１０３は、最初に順方向の深さ優先探索処理を実行することによって、各状態要素に番号を付与する（ステップS1410 ）。次いで、調整部１０３は、逆方向の深さ優先探索処理を実行することによって、状態要素群を複数の強連結成分に分解する（ステップS1420 ）。複数の強連結成分に分解した後、調整部１０３は、グループ分割処理を終了する。
以下、グループ分割処理を構成する副処理を説明する。最初に、ステップS1410 の順方向の深さ優先探索処理を説明する。図１３は、第１の実施形態の調整部１０３による順方向の深さ優先探索処理の動作を示すフローチャートである。図１３に示す処理は、グループ分割で使用される番号を付与する処理である。
調整部１０３は、全ての状態要素に番号が付与されるように、未探索の状態要素が残っているか否かを確認する（ステップS1411 ）。未探索の状態要素が残っていない場合（ステップS1411 におけるYes ）、調整部１０３は、順方向の深さ優先探索処理を終了する。
未探索の状態要素が残っている場合（ステップS1411 におけるNo）、調整部１０３は、未探索の状態要素を１つ取り出す。次いで、調整部１０３は、取り出された状態要素を起点とした深さ優先探索処理を実行することによって、各状態要素に番号を付与する（ステップS1412 ）。
ステップS1412 における深さ優先探索処理では、状態要素がノード、状態要素間の関係性がエッジとみなされる。また、各状態要素の探索が終了した後、調整部１０３は、探索された状態要素に番号を付与する以外に、管理ドメインにおける最大番号を記録する。深さ優先探索処理を終了した後、調整部１０３は、再度ステップS1411 の処理を行う。
例えば、図７（ｂ）に示す実線の枠内のシステム構成定義に対して、調整部１０３が状態要素"a" を起点とした深さ優先探索処理を実行した場合、図１４に示すように各状態要素に番号が付与される。
図１４は、グループ分割に用いられる番号が付与された状態要素の一例を示す説明図である。例えば、状態要素"a" であれば「a:9 」と記載されているため、番号「9 」が付与されている。また、二重枠で表現された状態要素は、深さ優先探索処理での起点の状態要素である。
図１５は、番号付与処理中の管理ドメインごとの記録情報の一例を示す説明図である。図１５は、管理ドメインD2において記録されている番号付与に関する情報の一例を示す。ステップS1410 の処理が終了した時点で、図１５に示すような情報が記録される。図１５に示すように、状態要素"b,f,g" それぞれに付与された番号が記録されている。また、管理ドメインD2における最大番号である番号「6 」と、最大番号が付与された状態要素"g" とが記録されている。
図１６は、番号付与の処理において協調部間で送受信される通信内容の一例を示す説明図である。図１６（ａ）は、状態要素"D2::g" から状態要素"D1::h" へ向けて探索を進める際に管理ドメインD2内の計画システムから送信される要求メッセージを示す。
また、図１６（ｂ）は、管理ドメインD1内の計画システムから送信される、図１６（ａ）に示す要求メッセージに対する返答メッセージを示す。管理ドメインを跨ぐ探索が行われる際に現時点での各管理ドメインの最大番号が双方に通知されることによって、全体的に連続した番号が付与される。
次に、ステップS1420 の逆方向の深さ優先探索処理を説明する。図１７は、第１の実施形態の調整部１０３による逆方向の深さ優先探索処理の動作を示すフローチャートである。図１７に示す処理は、グループ分割として状態要素群を複数の強連結成分に分解する処理である。
調整部１０３は、状態要素群を複数の強連結成分に分解するために、未探索の状態要素が残っているか否かを確認する（ステップS1421 )。未探索の状態要素が残っていない場合（ステップS1421 におけるYes ）、調整部１０３は、逆方向の深さ優先探索処理を終了する。
未探索の状態要素が残っている場合（ステップS1421 におけるNo）、調整部１０３は、未探索の状態要素のうち最大番号が付与された状態要素を起点とした逆向きの深さ優先探索処理を実行することによって、強連結成分を抽出する（ステップS1422 ）。
ステップS1421 〜ステップS1422 において調整部１０３は、未探索の状態要素や最大番号が付与された状態要素を、関連する複数の管理ドメイン全体から発見する。上記の処理を行うために、各管理ドメイン内の計画システムは、システム構成定義間の関係性の観点で関連する管理ドメインの情報を管理してもよい。
例えば、管理ドメインD1内の計画システムは、関連する管理ドメインとして管理ドメインD2の情報を管理してもよい。また、管理ドメインD2内の計画システムは、関連する管理ドメインとして管理ドメインD1の情報と管理ドメインD3の情報を管理してもよい。また、管理ドメインD3内の計画システムは、関連する管理ドメインとして管理ドメインD2の情報を管理してもよい。
管理対象の情報は、例えばステップS1330 の深さ優先探索処理において、計画システムが他の管理ドメインとの関係性を発見して探索要求を送る際や、他の管理ドメインから探索要求を受け付けた際に、相手の管理ドメインを記録することによって得られる。
関連する管理ドメインの情報が示す状態要素は全体としてグラフを形成するため、計画システムがグラフに対して深さ優先探索処理を実行することによって、未探索の状態要素や最大番号が付与された状態要素が発見される。
すなわち、ノードに相当する各管理ドメイン内の計画システムが、把握している未探索の状態要素の有無の情報を探索元の計画システムに返すことによって、全体としての未探索の状態要素の有無が認識される。また、ノードに相当する各管理ドメイン内の計画システムが、把握している最大番号を探索元の計画システムに返すことによって、全体としての最大番号が取得される。
ステップS1422 では、第１の深さ優先探索処理が実行されることによって、最大番号が付与された状態要素が発見される。また、第１の深さ優先探索処理において、強連結成分分解が行われるための第２の深さ優先探索処理がノードごとの処理として実行される。
ステップS1422 における深さ優先探索処理では、状態要素がノード、状態要素間の関係性を表す矢印の向きが反対の矢印がエッジとみなされる。また、調整部１０３は、探索の開始時に管理ドメインにおける新規のグループidを生成し、管理ドメインの情報として記録する。
探索によりノードが発見された際、調整部１０３は、発見されたノードに相当する状態要素を生成されたグループidが示すグループのメンバとして記録する。記録することによって管理ドメインにおける最大番号が変化する場合、調整部１０３は、最大番号を更新する。
また、他の管理ドメインへ探索が及んだ際に他の管理ドメインからメンバが新たにグループに参加すれば、調整部１０３は、他の管理ドメインをグループの関連ドメインとして記録する。
管理ドメインを跨ぐ探索を要求する際、調整部１０３は、メンバの探索中のグループのidを計画システムに通知する。要求を受けた管理ドメイン内の計画システムは、通知されたidが示すグループを自身のグループとして記録する。さらに、計画システムは、要求元の管理ドメインを記録されたグループの関連ドメインとして記録した上で、継続して探索を実行する。また、計画システムは、発見された状態要素を記録されたグループのメンバとして記録する。
図１８は、グループ分割に用いられる番号が付与された状態要素の他の一例を示す説明図である。図１４に示す状態要素間の矢印の向きと、図１８に示す状態要素間の矢印の向きは反対である。例えば、図１８に示す状態要素群に対して状態要素"a" を起点とした深さ優先探索処理を開始する際、管理ドメインD1内の調整部１０３は、新規のグループidとして"D1::G1"を生成し、記録する。
図１８に示す例に対する管理ドメイン内の記録情報の一例を図１９に示す。図１９は、強連結成分分解処理中の管理ドメインごとの記録情報の一例を示す説明図である。図１９は、逆方向の深さ優先探索処理が実行された際の記録情報を示す。図１９（ａ）は、管理ドメインD1内の記録情報を示す。また、図１９（ｂ）は、管理ドメインD2内の記録情報を示す。
図１９（ａ）を参照すると、状態要素"a,h" が探索された結果として、グループ"D1::G1"のメンバに状態要素"a" と状態要素"h" が記録されている。また、管理ドメインD1の最大番号が状態要素"i" の番号「8 」に更新されている。また、グループ"D1::G1"の関連ドメインに管理ドメインD2が記録されている。
図１９（ｂ）を参照すると、状態要素"b,f,g" が探索された結果として、グループ"D1::G1"のメンバに状態要素"b" 、状態要素"f" 、および状態要素"g" が記録されている。また、管理ドメインD2の最大番号が状態要素"y" の番号「10」に更新されている。また、グループ"D1::G1"の関連ドメインに管理ドメインD1が記録されている。
図２０は、強連結成分分解の処理において協調部間で送受信される通信内容の一例を示す説明図である。図２０（ａ）に示す要求メッセージには、グループidが含まれている。また、図２０（ｂ）に示す返答メッセージには、さらにグループに参加する新規メンバが存在する旨が記されている。
強連結成分分解の処理が実行された結果、図１８に示す状態要素群は、図２１に示す複数のグループに分割される。図２１は、ステップS1400 のグループ分割処理により生成されるグループの一例を示す説明図である。図２１に示す破線の楕円が、グループ分割処理により生成されるグループを表す。
次に、ステップS1500 のプランニングを説明する。図２２は、第１の実施形態の計画部１０２によるプランニングの全体動作を示すフローチャートである。
計画部１０２は、全てのグループに対して手順を探索するために、手順が未探索のグループが残っているか否かを全ての管理ドメインに渡って確認する（ステップS1510 ）。未探索のグループが残っていない場合（ステップS1510 におけるYes ）、計画部１０２は、プランニングを終了する。
未探索のグループが残っている場合（ステップS1510 におけるNo）、計画部１０２は、未探索のグループを１つ取り出す。次いで、計画部１０２は、取り出されたグループを起点とした深さ優先探索処理を実行することによって、手順探索可能なグループを探索しつつ、順次手順探索処理を実行する（ステップS1520 ）。深さ優先探索処理を実行した後、計画部１０２は、再度ステップS1510 の処理を行う。
手順探索可能なグループは、他のグループ内の手順探索済みでない状態要素と自グループ内の状態要素との間に関係性が無いようなグループである。または、手順探索可能なグループは、他のグループ内の手順探索済みでない状態要素との間に自グループ内の状態要素を指定する関係性が無いようなグループである。
図２１に示す例であれば、グループ"D1::G2"内の状態要素"i" は、グループ"D1::G1"内の状態要素"a" との間に自身を指定する関係性を有する。すなわち、グループ"D1::G2"は、手順探索可能なグループではない。
また、グループ"D1::G1"内の全ての状態要素は、他のグループ内の状態要素との間に上記のような関係性を有しない。すなわち、グループ"D1::G1"は、手順探索可能なグループである。なお、グループ"D1::G1"に対する手順探索処理が実行された後であれば、グループ"D1::G2"は手順探索可能なグループになる。
図２１に示す例において、手順が未探索のグループとして最初にグループ"D1::G2"が選択された場合、計画部１０２は、グループ"D1::G2"を起点として、グループがノード、グループ間の関係性を表す矢印の逆向きの矢印がエッジとみなされた第１の深さ優先探索処理を実行する。
次いで、計画部１０２が終端から順に手順探索処理を実行することによって、グループ"D1::G1"、グループ"D1::G2"の順に手順探索処理が実行される。以上で、ステップS1520 の処理である１回目の第１の深さ優先探索処理が終了する。以降、計画部１０２が同様の処理を繰り返し実行することによって、全てのグループに対して手順探索処理が実行される。
以下、プランニングを構成する副処理を説明する。最初に、ステップS1520 の手順生成処理を説明する。図２３は、第１の実施形態の計画部１０２による手順生成処理の動作を示すフローチャートである。図２３に示す処理は、１つのグループに関する手順計画処理である。
計画部１０２は、処理対象のグループが複数の管理ドメインを跨ぐか否かを確認する（ステップS1521 ）。複数の管理ドメインを跨いでいない場合（ステップS1521 におけるNo）、計画部１０２は、グループが存在する管理ドメイン内で手順探索処理を実行し、部分的な手順を生成する（ステップS1522 ）。部分的な手順を生成した後、計画部１０２は、ステップS1523 の処理を行う。
複数の管理ドメインを跨ぐ場合（ステップS1521 におけるYes ）、計画部１０２は、部分的な手順の生成処理を結合部１２０に依頼する（ステップS1530 ）。ステップS1530 の処理では、変更手順の生成処理の起点である管理ドメイン内の計画システムが、結合部１２０に対して処理対象のグループに対する手順探索処理を依頼する。結合部１２０は、関連する各管理ドメインにおける部分的な手順を生成する。
図２４は、協調部と結合部との間で送受信される通信内容の一例を示す説明図である。図２４（ａ）は、協調部から結合部へ送信される変更手順の生成処理の要求メッセージを示す。
図２４（ａ）に示す要求内容には、グループid以外に、依頼元の管理ドメインにおけるグループのメンバである状態要素や関連ドメインが含まれている。また、状態要素の情報として、手順探索に要する一連の情報である、取り得る状態、実行可能な状態遷移、現在状態、および目的状態までが含まれている。
図２４（ｂ）は、結合部から協調部へ送信される変更手順の生成処理の要求に対する返答メッセージを示す。図２４（ｂ）に示す返答内容には、処理結果に相当する部分的な手順を示す情報が含まれている。結合部１２０から部分的な手順を示す情報を受信した後、計画部１０２は、ステップS1523 の処理を行う。
次いで、計画部１０２は、得られた部分的な手順を、他のグループに対する手順生成処理で得られた部分的な手順と結合する（ステップS1523 ）。部分的な手順同士を結合した後、計画部１０２は、手順生成処理を終了する。
なお、グループが管理ドメインを跨ぐ場合には、グループに属するメンバが２つ以上の管理ドメインに存在する場合だけでなく、他の管理ドメイン内の状態要素との間に関係性を有する場合も含まれる。その理由は、関係性を有する他の管理ドメイン内の状態要素に対してもグループと共に手順探索処理が実行されることが求められるためである。
図２１に示す例であれば、グループ"D1::G1"、グループ"D2::G1"、およびグループ"D3::G1"が複数の管理ドメインを跨ぐグループであると判断される。
なお、ステップS1522 の手順探索処理は、例えば特許文献２に記載されている方法に従って実行される。また、ステップS1523 の部分的な手順の結合処理は、例えば特許文献３に記載されている方法に従って実行される。
以下、手順生成処理を構成するステップS1530 の手順探索処理を説明する。図２５は、第１の実施形態の結合部１２０による手順探索処理の動作を示すフローチャートである。
計画システム１００から部分的な手順の生成処理の依頼を受け付けると、結合部１２０は、関連ドメインに記載されている全ての管理ドメインから処理対象のグループに関連する状態要素を収集する（ステップS1531 ）。
次いで、結合部１２０は、収集された状態要素を結合することによって、手順探索問題を生成する（ステップS1532 ）。次いで、結合部１２０は、生成された手順探索問題に対して手順探索処理を実行し、システム構成の変更手順を生成する（ステップS1533 ）。
システム構成の変更手順を生成した後、結合部１２０は、生成された変更手順を各関連ドメインから収集された情報に基づいて分割する（ステップS1534 ）。次いで、結合部１２０は、分割で得られた各部分的な手順を、各管理ドメイン内の計画システムに通知する（ステップS1535 ）。各部分的な手順をそれぞれの計画システムに通知した後、結合部１２０は、手順探索処理を終了する。
図２６は、協調部と結合部との間で送受信される通信内容の他の一例を示す説明図である。図２６（ａ）は、結合部から協調部へ送信される情報の要求メッセージを示す。図２６（ａ）に示す要求内容には、結合部１２０が手順探索処理に要するグループidが含まれている。
図２６（ｂ）は、協調部から結合部へ送信される返答メッセージを示す。図２６（ｂ）に示す返答内容には、送信されたグループidが示すグループのメンバである状態要素の具体的な情報が含まれている。
図２７は、結合部１２０内に記録される情報の一例を示す説明図である。例えば、結合部１２０にグループ"D1::G1"の部分的な手順の生成処理が依頼された場合、結合部１２０は、全ての関連ドメインから手順探索処理に要する情報を収集する。
情報を収集した後、結合部１２０は、図２７に示すような管理ドメインごとの状態要素の情報を生成する。なお簡略化のため、図２７において状態要素"a" 以外の状態要素の内容を示す情報は省略されている。
図２７に示す状態要素"a" の事前状態制約内の"D2::b.s1"のような管理ドメインの情報が含まれる関係性から管理ドメインの情報が除去されると、一般的な手順探索問題と同様の形式の手順探索問題が得られる。結合部１２０が図２７に示す情報から生成された手順探索問題に対して手順探索処理を実行した結果、図２８に示すシステム構成の変更手順が生成された場合を考える。
図２８は、結合部１２０が生成するシステム構成の変更手順の一例を示す説明図である。図２８は、結合部１２０が生成した分割される前のシステム構成の変更手順を示す。図２８に示す矩形は、手順を表す。また、矩形内の文字が、手順で実行される作業を表す。
図２７に示す情報を参照することによって、結合部１２０は、状態要素"a" と状態要素"h" が管理ドメインD1に由来する状態要素であることが分かる。また、結合部１２０は、状態要素"b" 、状態要素"f" 、および状態要素"g" が管理ドメインD2に由来する状態要素であることが分かる。
よって、結合部１２０は、得られたシステム構成の変更手順を、管理ドメインD1に由来する手順"a(s1->s2)" および手順"h(s1->s2)" と、管理ドメインD2に由来する手順"g(s1->s2)" 、手順"f(s1->s2)" 、および手順"a(s1->s2)" に分割できる。
また、手順"a(s1->s2)" が実行された後に手順"b(s1->s2)" が実行されるような、生成された変更手順が複数の管理ドメインに渡る順序性を有する場合、結合部１２０は、適当な一意の識別情報として"D1::G1.X"等を生成する。
次いで、結合部１２０は、先に実行される手順"a(s1->s2)" の後に命令"call D1::G1.X" を配置する。また、結合部１２０は、後に実行される手順"b(s1->s2)" の前に命令"wait D1::G1.X" を配置する。
各命令が配置された変更手順を図２９に示す。図２９は、結合部１２０が生成するシステム構成の変更手順の他の一例を示す説明図である。図２９は、結合部１２０が生成した分割された後のシステム構成の変更手順を示す。
図２９（ａ）は、管理ドメインD1内の計画システムの実行対象である部分的な手順を示す。また、図２９（ｂ）は、管理ドメインD2内の計画システムの実行対象である部分的な手順を示す。以上のように、結合部１２０が手順探索処理を実行することによって、各計画システムの実行対象である部分的な手順が完成する。
以上の全ての処理が終了した後、例えば図７（ｄ）に示すような、管理ドメインごとに生成され、かつ管理ドメイン間で関連している一連のシステム構成の変更手順が形成される。各管理ドメイン内の計画システムは、管理ドメインごとに生成された部分的な手順を確認することによって、自身が管理するシステムにシステム構成変更が及ぼす影響を事前に確認できる。各管理ドメイン内の計画システムがそれぞれの制御装置４００等を用いて一斉にシステム構成の変更手順に従って変更処理を実行することによって、一連のシステム構成変更が協調的に実行される。
なお、本実施形態の計画システム１００の協調部１０１は、以下に示す処理を行ってもよい。
本実施形態に示す方法には、所定の管理ドメインで定義された状態要素の余分な情報まで他の管理ドメインや結合部１２０に通知されてしまうという問題がある。状態要素の情報は、基本的に状態要素を管理する管理ドメイン内の計画システムのみが把握していればよい。
例えば複数の管理ドメインを跨ぐ関係性が指定される際等には、状態要素を示すidや状態の情報に関して、別名が用いられてもよい。また、結合部１２０に手順計画を依頼する際にも、協調部１０１は、状態要素を示すidや取り得る状態の情報を別名に変換した上で依頼し、受け取った変更手順における別名を元の情報に読み替えればよい。
本実施形態の変形例として、協調部１０１は、状態要素の情報を、情報が匿名化された情報と対応付けて管理する情報テーブルを有する。他の管理ドメインや結合部１２０へ情報を送信する際、協調部１０１は、匿名化された情報を送信する。また、他の管理ドメインや結合部１２０から情報を受信した際、協調部１０１は、匿名化された情報を元の情報に戻す処理をさらに行う。
図３０は、管理ドメインごとの匿名情報の一例を示す説明図である。図３０（ａ）は、管理ドメインD1における匿名情報を示す。図３０（ｂ）は、管理ドメインD2における匿名情報を示す。本変形例の協調部１０１は、図３０に示すような状態要素や後述するフィールドに関する匿名情報を記録する。協調部１０１は、記録された匿名情報を用いて、匿名化処理や、匿名化された情報を元の情報に戻す処理を実行する。
図３０に示す" 再現情報" は、匿名化された情報から元の情報を得るために利用される対応情報である。また、" 匿名化情報" は、一貫性を持って元の情報を匿名化するために利用される対応情報である。
協調部１０１は、新たに匿名化の対象になる状態要素やフィールドが生じた場合、匿名を生成し" 匿名化情報" に追記する。協調部１０１は、ランダムな文字列等を適宜生成し匿名として用いればよい。
本変形例によれば、複数の管理ドメインそれぞれで管理されるシステムが関連する場合であっても、管理ドメイン間でシステム構成定義の内容が秘匿されたままシステム構成の変更手順が生成される。
［効果の説明］
本実施形態の計画システム１００は、複数の管理ドメインそれぞれで管理されるシステムが関連し、全体を把握している構成要素が存在しない場合であっても、システム構成の変更手順を生成できる。本実施形態では、複数の管理ドメインに影響を及ぼす一連のシステム構成変更が各管理ドメイン内の計画システムの協調動作により実現されるようなシステム構成の変更手順が、各管理ドメインで生成される部分的な手順の集合として生成される。
本実施形態の計画システム１００は、協調部１０１と、計画部１０２とを含む。システム構成定義は、構成要素の集合と構成要素間の関係性とで表現される。また、関係性には、他の計画システム群が管理するシステム構成定義内の構成要素との関係性が含まれる。
計画部１０２は、協調部１０１を介して他の計画システム群と通信し、協調して手順計画を実行する。協調して手順計画が実行されることによって、複数の管理ドメイン内の計画システムが協調して実行可能なシステム構成の変更手順の一部である、該当する管理ドメインに関するシステム構成の変更手順が生成される。
本実施形態の結合部１２０が使用されると、複数の管理ドメインそれぞれで管理されるシステム間に関係性が存在する場合であっても計画システムが利用される。各計画システムは、各管理ドメイン内で及ぶ影響を確認した上で、システム構成を変更できる。また、手順探索処理の実行のために状態要素を一箇所に集めることが避けられない場合であっても、本実施形態の調整部１０３は、集められる対象の状態要素の数を抑えることができる。
本実施形態の方法が使用されると、複数の管理ドメインそれぞれで管理されるシステムが関連する場合であっても計画システムが利用される。利用者は、各管理ドメイン内で及ぶ影響を確認した上で、システム構成を変更できる。
（第２の実施の形態）
［構成の説明］
次に、本発明の第２の実施形態を、図面を参照して説明する。図３１は、本発明による計画システムの第２の実施形態の構成例を示すブロック図である。
図３１に示すように、本実施形態の計画システム１００ａは、協調部１０１と、計画部１０２と、調整部１０３と、コンパイル部１０４とを含む。すなわち、本実施形態の計画システム１００ａの構成は、コンパイル部１０４が含まれる点以外は第１の実施形態の計画システム１００の構成と同様である。
コンパイル部１０４は、利用者がシステム構成の変更要求として入力した高級なシステム構成定義を、計画部１０２が処理できる低級なシステム構成定義に変換する機能を有する。なお、コンパイル部１０４は、計画部１０２と通信ネットワーク等を介して通信可能に接続されている。
第１の実施形態に示す状態要素群が用いられるシステム構成定義の表現方法には、大規模なシステム構成の定義の手動での表現が困難であるという問題がある。
特許文献３には、上記の問題を解決する、複数の状態要素群で構成された部分構成定義が再利用可能にまとめて抽象化されたコンポネントが用いられた高級なシステム構成定義を利用する方法が記載されている。
図３２は、一般的な高級なシステム構成定義の一例を示す説明図である。図３２に示す角丸四角形はコンポネントを表し、実線の矩形は状態要素を表す。角丸四角形内の文字がコンポネントの名称であり、実線の矩形内の文字が状態要素の名称である。なお簡略化のため、図３２には状態要素内の状態や状態遷移が示されていない。
図３２は、"component1"と"component2"の２つのコンポネントを示す。また、コンポネント"component1"には、"vm1" と"vm2" の２つの状態要素が含まれている。また、コンポネント"component2"には、状態要素"functionX2"が含まれている。
また、図３２に示す実線の山形および実線の矢羽形は、それぞれポートを表す。実線の山形の上の文字および実線の矢羽形の左上の文字がポートの名称である。一般的な高級なシステム構成定義では、コンポネントは、他のコンポネントとポートを介して結合する。ポート間の接続は、ワイヤとも呼ばれる。
ポートには、機能を要求するリファレンスポートと、機能を提供するサービスポートがある。リファレンスポートは、要求する機能の情報を有する。また、サービスポートは、提供する機能の情報を有する。ワイヤは、常に同じ機能の情報を有するリファレンスポートとサービスポートとを接続するように定義される。
図３２に示すように、リファレンスポートは実線の山形で、サービスポートは実線の矢羽形で、ワイヤはポート間の二重線でそれぞれ表現される。図３２に示すリファレンスポート"reference1"、およびサービスポート"service2"は、共に"API1"という機能の情報を有する。
また、図３２に示す破線の矩形、および破線の山形は、それぞれフィールドを表す。破線の矩形の左上の文字および破線の山形の上の文字がフィールドの名称である。フィールドは、状態要素を格納するコンポネントの構成要素である。なお、山形のフィールドは、後述するようにポート内でのみ定義される特殊なフィールドである。
一般的な高級なシステム構成定義では、状態要素間の関係性は、フィールドを介して抽象的に定義される。例えば、コンポネント"component1"のフィールド"vm12"とフィールド"agent1"との間に関係性が定義されている。すなわち、フィールド"vm12"に格納された状態要素"vm2" と、フィールド"agent1"に格納された状態要素"agentD1" との間に、フィールド間に定義された関係性と同様の関係性が存在すると解釈される。
また、図３２に示す状態要素"agentD1" は、制御モジュールを表す特殊な状態要素である。図３２に示すように、制御モジュールは、二重線の矩形で表現される。また、状態要素"A" が制御モジュール"B" で制御されるという関係性は、両端に黒丸を有する実線で表現される。
すなわち、図３２に示すフィールド"vm12"とフィールド"agent1"との間に存在する実線は、フィールド"vm12"内の状態要素の配備や削除等の操作がフィールド"agent1"内の制御モジュール"agentD1" により実行されることを表す。
また、図３２に示す状態要素"redundant" は、複数の状態要素に渡る一般的な制約条件を表す特殊な状態要素である。条件の内容は、それぞれの制約条件ごとに定義される。図３２に示すように、制約条件は、三重線の矩形で表現される。また、状態要素が制約条件に従うことは、事前状態制約と同様に、制約条件から状態要素へ伸びる破線の矢印で表現される。
図３２に示す制約条件"redundant" は、関連する状態要素"vm1" と状態要素"vm2" のうち、少なくとも１つは起動状態になるように、計画部１０２による手順計画の動作や制御装置４００の動作等を制約する。
複数のコンポネントが結合されると、各コンポネントが含む状態要素が一括で関係付けられる。例えば、図３２に示すコンポネント"component1"内の状態要素"vm1" は、コンポネント"component2"内の制御モジュール"agentD2" と関係付けられる。
その理由は、状態要素"vm1" は、ポートを介してコンポネント"component2"内のフィールド"vm21"にまで接続されている。すなわち、フィールド"vm21"とフィールド"agent2"との間に定義された関係性を、状態要素"vm1" も有するからである。
同様に、コンポネント"component2"内の状態要素"functionX2"は、コンポネント"component1"内の状態要素"vm1" 、および状態要素"vm2" とそれぞれ関係付けられる。
上記のような定義が表現されるために、一般的な高級なシステム構成定義では、ポート内にフィールドが定義される。また、コンポネント内のフィールドに格納されている状態要素が、コンポネントが有するポート内のフィールドまで接続される。
ポート内のフィールドには、右向きの山形で表現されるアクセプトフィールドと、左向きの山形で表現されるプロバイドフィールドとがある。状態要素は、アクセプトフィールドを介してリファレンスポートからサービスポートに接続される。また、状態要素は、プロバイドフィールドを介してサービスポートからリファレンスポートに接続される。
図３２に示す例では、コンポネント"component1"が有するポート"reference1"内にフィールド"vm"が定義されている。また、フィールド"vm"は、フィールド"vm11"を参照している。すなわち、フィールド"vm11"に格納されている状態要素"vm1" が、ポート"reference1"内のフィールド"vm"まで接続される。
図３２に示すように、フィールドによる状態要素の参照は、フィールド内の黒丸が始点である矢印で表現される。なお、状態要素の接続の方向は、参照を表現する矢印の向きと逆の方向である。
上記の通り、結合される２つのポートは、同じ機能の情報を有する。また、同じ機能の情報を有するポート同士は、対応するフィールドを含む。
図３２に示す状態要素"vm1" は、ポート"reference1"内のフィールド"vm"からさらにポート"service2"内のフィールド"vm"まで接続される。最終的に、状態要素"vm1" は、フィールド"vm"からコンポネント"component2"内のフィールド"vm21"まで接続される。
上記のような表記が用いられるため、高級なシステム構成定義が使用されると、同じ機能を有するポートを含むコンポネント同士であれば、異なるコンポネントが組み合わせられて表現される。すなわち、多様なシステム構成が定義される点が、上記の高級なシステム構成定義が使用される場合の利点である。フィールドを介して関係性が指定される点や、状態要素が複数のフィールドに接続される点も、同様の利点が得られるための特徴である。
一般的な高級なシステム構成定義の低級なシステム構成定義へのコンパイルは、コンポネントやコンポネント間の結合関係に関する定義を基にコンポネント内の状態要素同士を関係付けることによって得られる状態要素群を生成する処理である。
図３２に示すシステム構成定義がコンパイルされた結果を図３３に示す。図３３は、高級なシステム構成定義がコンパイルされた低級なシステム構成定義の一例を示す説明図である。
本実施形態の高級なシステム構成定義では、異なる管理ドメインに存在する複数のコンポネントが結合されている。本実施形態のコンパイル部１０４は、異なる管理ドメインに存在する複数のコンポネントが結合されている高級なシステム構成定義を基に、複数の管理ドメインに跨る低級なシステム構成定義を生成する。
上記の処理が実現されるために、本実施形態のシステム構成定義では、サービスポートが外部に公開されるように指定されたり、外部に公開された他の管理ドメイン内のポートとの結合関係が定義されたりする。
図３４は、第２の実施形態の高級なシステム構成定義の一例を示す説明図である。図３４は、管理ドメインD2におけるシステム構成定義を示す。図３４に示すメタ情報には、コンポネント"component2"が有するサービスポート"service2"が提供するサービスが、" 公開サービス" であることが指定されている。なお、メタ情報は、システム構成定義内の情報をさらに定義する情報である。
図３５は、第２の実施形態の高級なシステム構成定義の他の一例を示す説明図である。図３５は、管理ドメインD1におけるシステム構成定義を示す。図３５に示すポート"D2::component2.service2" は、リファレンスポート"reference1"が管理ドメインD2内のコンポネント"component2"が有するサービスポート"service2"を参照していることを示す。すなわち、リファレンスポート"reference1"がサービスポート"D2::component2.service2" に接続されることによって、複数の管理ドメインを跨るワイヤが定義される。
なお、図３５に示す"component2.service2" のような"." で名詞を繋ぐ表現は、"component2"の中の"service2"という包含関係を表す。他の記載も同様の意味を有する。
図３４に示す高級なシステム構成定義が単独でコンパイルされると、管理ドメインD2内に図３６に示すような低級なシステム構成定義が生成される。図３６は、第２の実施形態の高級なシステム構成定義がコンパイルされた低級なシステム構成定義の一例を示す説明図である。
図３５に示す高級なシステム構成定義を定義に関連する管理ドメインD1内の計画システムと管理ドメインD2内の計画システムが協調した上でコンパイルすると、各管理ドメイン内に図３７に示すような低級なシステム構成定義が生成される。図３７は、第２の実施形態の高級なシステム構成定義がコンパイルされた低級なシステム構成定義の他の一例を示す説明図である。
例えば、２つのシステム構成定義を比較し、２つの定義の差分に基づいて各状態要素の現在状態と目的状態を決定する方法がある。図３６に示すシステム構成定義と図３７に示すシステム構成定義との差分から得られるシステム構成の変更要求定義を図３８に示す。
図３８は、第２の実施形態のシステム構成の低級な変更要求定義の一例を示す説明図である。図３８に示す状態"t" は、状態要素が存在する状態を表す。また、状態"f" は、状態要素が存在しない状態を表す。
例えば、状態要素"functionX2"は、図３６に示すシステム構成定義と図３７に示すシステム構成定義の両方に存在するため、現在状態および目的状態がいずれも状態"t" になる。また、状態要素"vm1" と状態要素"vm2" は、図３７に示すシステム構成定義にのみ存在するため、現在状態が状態"f" 、目的状態が状態"t" にそれぞれなる。
図３８に示すシステム構成の変更要求定義は、制約条件"redundant" 以外に関して、第１の実施形態に示す方法で計画部１０２により処理される。制約条件は、後述するように処理される。また、本実施形態の計画部１０２は、本実施形態の制御モジュールを単純に無視してもよい。
本実施形態では、制約条件や制御モジュールではない一般的な状態要素は、コンパイルの過程で１つの制御モジュールと関連付けられたフィールドに接続される。コンパイルされた後にフィールドに接続された状態要素は、フィールドが管理される管理ドメインにおいて管理される。本実施形態では、状態要素が接続されたフィールドを状態要素に関する管理フィールドと呼ぶ。
また、関係性は、状態要素の接続経路上のいずれのフィールドでも定義される。しかし、全ての関係性は、コンパイルされた後に各状態要素に関する管理フィールドにおいて定義される識別情報に基づいた関係性に変換されることが求められる。
［動作の説明］
以下、本実施形態の計画システム１００ａの動作を図３９〜図４０を参照して説明する。図３９は、第２の実施形態の計画システム１００ａによる高級なシステム構成定義のコンパイル処理の具体例を示す説明図である。
図３９に示す矩形はフィールドを表し、実線の矢印は状態要素の接続経路を表す。また、二重線の矩形は、システム構成定義で状態要素を格納するように定義されたフィールドを表す。また、黒色の矩形は、制御モジュールと関連付けられたフィールドを表す。
また、図３９に示すフィールド内の文字は、フィールドのidと、接続された状態要素のidを表す。例えば、フィールド内の「a:A 」は、フィールドのidが「a 」であり、接続された状態要素のidが「A 」であることを表す。
また、図３９（ａ）に示すフィールド"c" からフィールド"y" へ伸びるように定義された関係性は、図３９（ｄ）に示す管理フィールドにおいて定義された識別情報であるフィールド"d:A" からフィールド"z:X" へ伸びる関係性に変換されている。
上記の処理は、図３５に示すフィールド"D1::component1.vm12" からフィールド"D1::component1.reference1.functionX" へ伸びるように定義された関係性が、図３７に示す状態要素"D1::vm2" から状態要素"D2::functionX2"へ伸びる関係性に変換される処理に相当する。
各状態要素に関して、最初に接続経路上のフィールドで構成されたグラフと管理フィールドが識別される。図３９（ａ）に示す例では、フィールド"a" に状態要素"A" が含まれる場合、フィールド"a" を起点とした深さ優先探索処理が行われることによって状態要素"A" の管理フィールドがフィールド"d" であると識別される。
識別された結果、フィールド"a" 内に状態要素"A" の管理フィールドがフィールド"d" であることが記録される。図３９において、記録された情報はフィールドの上の吹き出しの中に示されている。
また、フィールド"a" からフィールド"d" に至る経路に存在するフィールド"b" とフィールド"c" は、状態要素"A" の主要な接続経路上のフィールドとして記録される。図３９に示す実線の矩形は、主要な接続経路上のフィールドを表し、点線の矩形は他のフィールドを表す。コンパイル部１０４は、同様の操作をフィールド"x" 内の状態要素"X" に対しても実行する。
次いで、コンパイル部１０４は、決定された管理フィールドの情報を接続経路上の各フィールドに通知する。図３９（ｂ）は、管理フィールドの情報が通知された時点のシステム構成定義の状態を示す。
次いで、コンパイル部１０４は、管理フィールドを起点として接続経路のグラフに対して深さ優先探索処理を実行し、関係性を収集する。深さ優先探索の起点を管理フィールドにするために、コンパイル部１０４は、上記の「主要な接続経路」における探索方向の逆向きに探索処理を行う。
その理由は、例えば、図３９（ａ）に示すフィールド"d" を起点として状態要素"A" の接続経路を探索する場合、フィールド"c,b,a" の探索には該当部分のエッジの向きを反転させることが求められるためである。
図３９（ｃ）に示す例では、フィールド"d" を起点とした状態要素"A" の探索において、フィールド"c" でフィールド"y" との関係性の定義が発見される。続いて、フィールド"y" に記録された状態要素"X" の管理フィールドであるフィールド"z" が参照されることによって、関係性が最終的にフィールド"z:X" と結ばれればよいことがわかる。
図３９（ｄ）は、生成されたコンパイル結果を示す。第２の実施形態のコンパイル部１０４は、上記のような動作を複数の管理ドメイン内の計画システムと協調しながら実行する。
図４０は、第２の実施形態の計画システム１００ａによる高級なシステム構成定義のコンパイル処理の動作を示すフローチャートである。
本実施形態の計画部１０２は、入出力装置２００を介して利用者からシステム構成の変更要求を受け付ける（ステップS2100 ）。次いで、計画部１０２は、受け付けられたシステム構成の変更要求が一意に特定される変更要求idを生成する。
次いで、計画部１０２は、システム構成の変更要求に関する情報を記録するための記憶領域を記憶装置３００に生成する。記憶領域を生成した後、計画部１０２は、システム構成の変更要求をコンパイル部１０４に転送する。
コンパイル部１０４は、転送されたシステム構成の変更要求内の高級なシステム構成定義から、自身が存在する管理ドメイン以外の関連する管理ドメイン内のポートの情報を抽出する。次いで、コンパイル部１０４は、協調部１０１を介して関連する管理ドメイン内の計画システムにコンパイル処理の開始を要求する（ステップS2200 ）。
コンパイル処理の開始の要求を受け付けた管理ドメイン内の計画システムは、コンパイル処理に関する記憶領域を生成する。図４１は、コンパイル処理の開始の要求時および返答時に送受信される通信内容の一例を示す説明図である。図４１（ａ）は、コンパイル処理の開始の要求メッセージを示す。また、図４１（ｂ）は、コンパイル処理の開始の要求に対する返答メッセージを示す。
次いで、関連する全ての管理ドメイン内のコンパイル部１０４は、状態要素が定義されたフィールドを起点として、フィールドがノードであり、参照を表す矢印の逆向きの矢印がエッジである深さ優先探索処理を実行する。コンパイル部１０４は、各状態要素の接続経路で構成されたグラフを形成すると共に、管理フィールドを識別する（ステップS2300）。
例えば、図３５に示す状態要素"vm1" に関する深さ優先探索処理では、最初に状態要素"vm1" が格納されたフィールド"component1.vm11" が、探索が開始されるフィールドになる。フィールド"component1.vm11" は別のフィールド"component1.reference1.vm"から参照されているため、フィールド"component1.reference1.vm"は、接続経路上の次のノードの１つになる。
次いで、ポート"reference1"が他の管理ドメイン内のポート"D2::component2.service2" に接続されているため、探索を依頼された管理ドメインD2内の計画システムが探索を継続して実行する。
図４２は、管理フィールドの探索の要求時および返答時に送受信される通信内容の一例を示す説明図である。図４２（ａ）は、管理フィールドの探索の要求メッセージを示す。図４２（ａ）に示すように、探索を依頼する側の管理ドメイン内の計画システムは、探索対象の状態要素を示すidと探索先のフィールドを要求メッセージに含める。
また、図４２（ｂ）は、管理フィールドの探索の要求に対する返答メッセージを示す。図４２（ｂ）に示すように、探索が依頼される側の管理ドメイン内の計画システムは、状態要素の管理フィールドが発見されれば、発見された管理フィールドを返答する。
また、図４３は、管理フィールドの探索中の管理ドメインごとの記録情報の一例を示す説明図である。図４４は、管理フィールドの探索中の管理ドメインごとの記録情報の他の一例を示す説明図である。図４３および図４４に示すように、各状態要素の深さ優先探索処理の開始時に、計画システムは、最初に" 状態要素" の項目に探索対象の状態要素を示す情報と開始フィールドを記録する。
各フィールドが探索された際、計画システムは、記録された状態要素の中の" 接続経路" の項目に探索されたフィールドを示すidを追記する。また、計画システムは、フィールド間の参照関係に基づいて、接続経路上の次のフィールドや前のフィールドを記録する。
探索されたフィールドが管理フィールドであれば、計画システムは、探索されたフィールドを状態要素の管理フィールドとして" 管理フィールド" の項目に記録する。フィールドの探索を終えて探索元の計画システムに処理を戻す際、計画システムは、管理フィールドが発見されていれば状態要素の" 主要な接続経路" に"yes" を記録する。
また、管理フィールドが発見されていなければ、計画システムは、状態要素の" 主要な接続経路" に"no"を記録する。" 主要な接続経路" に情報を記録した上で、計画システムは、探索元の計画システムに管理フィールドの情報を返す。
他の管理ドメイン内の計画システムから探索を依頼された場合、計画システムは、最初に" 状態要素" の項目に依頼された探索対象の状態要素を示す情報を記録する。記録した後、計画システムは、接続経路上のフィールドを示す情報を同様に追記する。
図４３は、探索対象の状態要素が管理ドメインD1内の状態要素"vm1"や状態要素"D2::functionX2"である記録情報を示す。また、図４４は、探索対象の状態要素が状態要素"D1::vm1" や管理ドメインD2内の状態要素"functionX2"である記録情報を示す。
なお、全く接続しない状態要素は、図４３に示す管理ドメインD1内の状態要素"vm2" のように、開始フィールドと管理フィールドがフィールド"component1.vm12" で同一である。また、接続経路にも、フィールド"component1.vm12" のみが含まれる。図４３において、状態要素"vm2" 以外の接続しない状態要素の具体的な情報は省略されている。
次いで、関連する全ての管理ドメイン内のコンパイル部１０４は、状態要素が定義されたフィールドを起点として、フィールドがノードであり、参照を表す矢印の逆向きの矢印がエッジである深さ優先探索処理を実行する。コンパイル部１０４は、各フィールドに各状態要素の管理フィールドを記録する（ステップS2400 ）。
図４５は、管理フィールドの情報が通知された後の管理ドメインごとの記録情報の一例を示す説明図である。図４５（ａ）は、管理ドメインD1における記録情報を示す。図４５（ｂ）は、管理ドメインD2における記録情報を示す。
次いで、関連する全ての管理ドメイン内のコンパイル部１０４は、管理フィールドを起点とした深さ優先探索処理を実行し、関係性を示す情報を収集する（ステップS2500 ）。例えば、図４４に示す" 管理フィールド" には、状態要素"D1::vm1" の管理フィールドが"component2.vm21" であると記録されている。
よって、コンパイル部１０４は、図４４に示す" 状態要素" の項目の"D1::vm1" における"component2.vm21" から探索を開始する。基本的に探索対象は" 次のフィールド" に記載されたフィールドである。なお、" 次のフィールド" に記載されたフィールドが主要な接続経路上に存在すれば、すなわち" 主要な接続経路" の項目が"yes" であれば、" 前のフィールド" に記載されたフィールドも探索の対象になる。
探索中に関係性が発見された場合、コンパイル部１０４は、管理フィールドを参照して、発見された関係性に管理フィールドが加えられた情報を探索元の計画システムに返す。図３５に示す例では、フィールド"component1.vm11" は、フィールド"component1.reference1.functionX" やフィールド"component1.redundant"との間に関係性が定義されている。
フィールド"component1.vm11" の探索時に上記の関係性の定義が発見されると、コンパイル部１０４は、図４５（ａ）に示す情報を参照する。参照することによって、コンパイル部１０４は、フィールド"component1.reference1.functionX" には状態要素"D2::functionX2"が含まれており、状態要素"D2::functionX2"の管理フィールドが"D2::component2.functionX"であることを把握する。
また、コンパイル部１０４は、フィールド"component1.redundant"には状態要素"redundant" が含まれており、状態要素"redundant" の管理フィールドが"component1.redundant"であることを把握する。コンパイル部１０４は、把握された情報をまとめて探索元の計画システムに返す。
図４６は、関係性の収集の要求時および返答時に送受信される通信内容の一例を示す説明図である。図４６（ａ）は、関係性の収集の要求メッセージを示す。また、図４６（ｂ）は、関係性の収集の要求に対する返答メッセージを示す。図４６に示すように、状態要素を示すidと管理フィールドを示すidとが" @" で繋がれている。" @" で繋がれた情報は、まとめられた情報を表現している。
各管理ドメイン内のコンパイル部１０４は、管理フィールドごとに全ての状態要素に関する関係性の情報を取りまとめる。図４７は、管理ドメインごとに関係性がまとめられた記録情報の一例を示す説明図である。図４７（ａ）は、管理ドメインD1における記録情報を示す。図４７（ｂ）は、管理ドメインD2における記録情報を示す。
次いで、コンパイル部１０４は、全ての状態要素に関して、管理フィールドを有する各管理ドメインに状態要素の取り得る状態や実行可能な状態遷移等の手順計画に要する情報を通知する。各管理ドメイン内の計画システムは、通知された情報を状態要素に追加し、低級なシステム構成定義を完成させる。
コンパイル部１０４は、完成された低級なシステム構成定義を計画部１０２に入力する（ステップS2600 ）。入力した後、計画システム１００ａは、高級なシステム構成定義のコンパイル処理を終了する。
なお、本実施形態で例示された"redundant" のような制約条件に対する調整部１０３による影響範囲抽出処理の方法やグループ分割処理の方法は、事前状態制約に対する各方法と異なる。以下、制約条件に関して異なる点を補足する。
影響範囲抽出処理の方法が異なる理由を説明するために、例えば制約条件の内容が「関連する状態要素のうち少なくとも１つの状態は状態"t" であること」という場合を考える。１つの状態要素の状態が状態"f" になるのであれば、他の状態要素のうちの少なくとも１つの状態要素の状態を状態"t" に変更することが求められる。よって、制約条件に対する影響範囲抽出処理の方法は、事前状態制約に対する方法と異なる。
上記のように、影響範囲の判定方法は、制約条件の内容に依存する。しかし、少なくとも関連する全ての状態要素が影響範囲に加えられれば、手順計画は正しく実行される。
よって、影響範囲を探索する際、調整部１０３は、所定の状態要素が変更される場合には変更される状態要素を参照する制約条件に影響が及ぶ可能性があると判断して探索すればよい。反対に、所定の制約条件が変更される場合、調整部１０３は、変更される制約条件が参照する全ての状態要素に影響が及ぶ可能性があると判断して探索すればよい。
また、同様にグループ分割処理では、所定の制約条件と参照対象の全ての状態要素が同じグループに所属することが求められる。制約条件と参照対象の全ての状態要素を同じグループに所属させるために、調整部１０３は、強連結成分分解において単に所定の制約条件と状態要素群との間にそれぞれに向いた２つのエッジが存在すると解釈して探索すればよい。
なお、本実施形態に示す制約条件等が用いられて各管理ドメインに許容可能なシステム構成の変更手順の条件が事前に設定されれば、各管理ドメイン内の計画システムは、設定された条件に違反しないことを前提にシステム構成変更の実行を自動的に許可してもよい。
また、計画システムは、実行を許可した旨をシステム構成変更が受け付けられた管理ドメインに通知してもよい。すなわち、システム構成変更の受け付けから複数の管理ドメインを跨る変更までの処理全体が自動的に実行される。
なお、本実施形態の協調部１０１も、第１の実施形態の変形例と同様に、情報の匿名化処理を行ってもよい。ただし、図３４および図３５に示す外部に公開されるポートや、外部に公開されるポートに接続される状態要素の情報は、そもそも他の管理ドメインに通知されることが意図された情報であるため、匿名化処理の対象外である。
本実施形態において匿名化および再現の対象になる通信には、ステップS2300 での管理フィールドを発見する際に行われる通信、ステップS2400 での接続経路上のフィールドに通知する際に行われる通信がある。また、ステップS2500 での関係性を収集する際に行われる通信、計画システムと結合部との間で行われる通信がある。
上記の通信の内容が匿名化された例を図４８〜図５０に示す。図４８は、管理フィールドの探索の要求時および返答時に送受信される通信内容の他の一例を示す説明図である。図４８（ａ）は、管理フィールドの探索の要求メッセージを示す。また、図４８（ｂ）は、管理フィールドの探索の要求に対する返答メッセージを示す。図４８に示すように、状態要素の情報が匿名化されている。
図４９は、関係性の収集の要求時および返答時に送受信される通信内容の他の一例を示す説明図である。図４９（ａ）は、関係性の収集の要求メッセージを示す。また、図４９（ｂ）は、関係性の収集の要求に対する返答メッセージを示す。図４９に示すように、状態要素の情報や事前状態制約の情報等が匿名化されている。
図５０は、協調部と結合部との間で送受信される通信内容の他の一例を示す説明図である。図５０（ａ）は、協調部から結合部に送信される要求メッセージを示す。また、図５０（ｂ）は、結合部から協調部に送信される返答メッセージを示す。図５０に示すように、事前状態制約の情報等が匿名化されている。
［効果の説明］
本実施形態の方法が使用されると、複数の管理ドメインそれぞれで管理されるシステムが関連する場合であっても計画システムが利用される。利用者は、各管理ドメイン内で及ぶ影響を確認した上で、システム構成を変更できる。
また、本実施形態の計画システムは、複数の管理ドメインそれぞれで管理されるシステムが関連する場合であっても、高級なシステム構成定義を用いてシステム構成の変更手順を生成できる。その理由は、コンパイル部１０４が高級なシステム構成定義を、調整部１０３が処理できる低級なシステム構成定義に変換できるためである。
なお、各実施形態の計画システム１００、計画システム１００ａ、他の計画システム１１０、および結合部１２０は、例えば、記憶媒体に格納されているプログラムに従って処理を実行するCPU(Central Processing Unit)によって実現される。すなわち協調部１０１、計画部１０２、調整部１０３、およびコンパイル部１０４は、例えば、プログラム制御に従って処理を実行するCPU によって実現される。
また、各実施形態の計画システム１００、および計画システム１００ａにおける各部は、ハードウェア回路によって実現されてもよい。一例として、協調部１０１、計画部１０２、調整部１０３、およびコンパイル部１０４が、それぞれLSI(Large Scale Integration)で実現される。また、それらが１つのLSI で実現されていてもよい。
次に、本発明の概要を説明する。図５１は、本発明による協調計画システムの概要を示すブロック図である。本発明による協調計画システム１０は、システム構成をそれぞれ管理する複数の計画システム２０１〜２０Ｎ（例えば、計画システム１００）と、複数のシステム構成の変更要求に対する変更手順を生成する生成部３０（例えば、結合部１２０）とを含む協調計画システムであって、生成部３０は、複数の計画システム２０１〜２０Ｎから入力された複数のシステム構成の定義を基に変更手順を生成し、生成された変更手順を各システム構成の要素に関する手順ごとに分割することによって複数の部分的な手順を生成し、実行が完了すると第２の部分的な手順に含まれる第２の手順の実行が開始される第１の手順を含む第１の部分的な手順に対して第２の部分的な手順を実行する計画システムに手順の完了を示す情報を入力する手順を第１の手順の後に追加し、第２の部分的な手順に対して第１の部分的な手順を実行する計画システムから手順の完了を示す情報が入力される手順を第２の手順の前に追加する。
そのような構成により、協調計画システムは、複数の管理ドメインに影響を及ぼすシステムの構成変更の手順を各管理ドメイン内で生成される部分的な手順の集合として生成できる。
また、計画システム２０１〜２０Ｎは、管理対象のシステム構成の定義を加工した上で生成部３０に入力する入力部（例えば、協調部１０１）を含み、入力部は、複数のシステム構成の変更要求に基づいて管理対象のシステム構成の定義から変更対象の部分を抽出し、抽出された変更対象の部分を生成部３０に入力してもよい。
そのような構成により、協調計画システムは、機密性のより高い状態でシステム構成の変更手順をより高速に生成できる。
また、入力部は、抽出された変更対象の部分を１つ以上の強連結成分に分解した上で生成部３０に入力してもよい。
そのような構成により、協調計画システムは、システム構成の変更手順をより高速に生成できる。
また、入力部は、管理対象のシステム構成の定義の内容を匿名化した上で生成部３０に入力してもよい。
そのような構成により、協調計画システムは、機密性のより高い状態でシステム構成の変更手順を生成できる。
また、生成部３０は、生成された複数の部分的な手順を各計画システム２０１〜２０Ｎの入力部にそれぞれ入力し、入力部には、入力された部分的な手順の実行に要する情報が他の計画システムから入力されてもよい。
そのような構成により、協調計画システムは、計画システム同士が協調した状態でシステム構成を変更できる。
また、入力部は、入力された部分的な手順に含まれる匿名化された情報を元の情報に変換してもよい。
そのような構成により、協調計画システムは、機密性のより高い状態でシステム構成を変更できる。
また、管理対象のシステム構成の定義は、１つ以上のシステム構成の要素群と要素間の関係性を含む定義情報であるコンポネントと、コンポネントが他のコンポネントと接続されるための点を示す定義情報であるポートと、ポート間の接続に関する定義情報であるワイヤとを含む高級なシステム構成定義であり、計画システム２０１〜２０Ｎは、高級なシステム構成定義を要素群と要素間の関係性とで構成される低級なシステム構成定義に変換する変換部（例えば、コンパイル部１０４）を含んでもよい。
そのような構成により、協調計画システムは、手動でより容易に生成されるシステム構成定義を基にシステム構成の変更手順を生成できる。
また、計画システム２０１〜２０Ｎが管理する高級なシステム構成定義は、他の計画システムが管理する高級なシステム構成定義内のポートの情報を含んでもよい。
そのような構成により、協調計画システムは、複数の管理ドメインに跨る高級なシステム構成定義を基にシステム構成の変更手順を生成できる。
なお、計画システム２０１〜２０Ｎと生成部３０は、通信ネットワークを介して通信可能に接続されていてもよい。また、計画システム２０１〜２０Ｎは、外部の入出力装置および記憶装置と通信ネットワークを介して通信可能に接続されていてもよい。また、入力部は、他の計画システムと通信ネットワークを介して通信可能に接続されていてもよい。
また、計画システム２０１〜２０Ｎは、入出力装置を介して利用者からシステム構成の変更要求を受け付けた時に、入力部を介して関連する全ての計画システムと通信し、いずれかの計画システムを生成部３０として利用することによって手順計画を実行してもよい。
例えば、システム構成の変更要求を受け付けた計画システムが生成部３０として利用されてもよいし、一度各計画システム２０１〜２０Ｎが管理する状態要素の数が確認された上で最も多くの状態要素を管理する計画システムが生成部３０として利用されてもよい。
生成部３０として利用される計画システムは、各計画システム２０１〜２０Ｎから状態要素を収集し、手順計画を実行し、実行結果を分割することによって部分的な手順を生成し、生成された部分的な手順を各計画システム２０１〜２０Ｎに返信する。
また、各計画システム２０１〜２０Ｎが管理するシステム構成の定義には、１つ以上の構成要素とシステム構成の定義間の関係性とが含まれ、各構成要素は、構成要素が取り得る１つ以上の状態と実行可能な状態遷移の情報を含み、システム構成の定義間の関係性は、少なくともシステム構成の定義内の構成要素の状態遷移が実行される事前制約としての他のシステム構成の定義内の構成要素の状態の指定、システム構成の定義内の条件判断に要する他のシステム構成の定義内の構成要素の指定、システム構成の定義内の構成要素を制御する他のシステム構成の定義内の制御モジュールの指定のいずれかを表してもよい。
また、複数の計画システム２０１〜２０Ｎのうちのいずれか１つの計画システムが、他の計画システムに対して生成部３０に入力されるシステム構成の定義を指定してもよい。
以上、実施形態および実施例を参照して本願発明を説明したが、本願発明は上記実施形態および実施例に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。
この出願は、２０１６年１０月２０日に出願された日本特許出願２０１６−２０５８４１を基礎とする優先権を主張し、その開示の全てをここに取り込む。
また、上記の実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下に限られない。
（付記１）システム構成をそれぞれ管理する複数の計画システムと、複数のシステム構成の変更要求に対する変更手順を生成する生成部とを含む協調計画システムであって、前記生成部は、前記複数の計画システムから入力された複数のシステム構成の定義を基に前記変更手順を生成し、生成された前記変更手順を各システム構成の要素に関する手順ごとに分割することによって複数の部分的な手順を生成し、実行が完了すると第２の部分的な手順に含まれる第２の手順の実行が開始される第１の手順を含む第１の部分的な手順に対して前記第２の部分的な手順を実行する計画システムに手順の完了を示す情報を入力する手順を前記第１の手順の後に追加し、前記第２の部分的な手順に対して前記第１の部分的な手順を実行する計画システムから前記手順の完了を示す情報が入力される手順を前記第２の手順の前に追加することを特徴とする協調計画システム。
（付記２）計画システムは、管理対象のシステム構成の定義を加工した上で生成部に入力する入力部を含み、前記入力部は、複数のシステム構成の変更要求に基づいて前記管理対象のシステム構成の定義から変更対象の部分を抽出し、抽出された前記変更対象の部分を前記生成部に入力する付記１記載の協調計画システム。
（付記３）入力部は、抽出された変更対象の部分を１つ以上の強連結成分に分解した上で生成部に入力する付記２記載の協調計画システム。
（付記４）入力部は、管理対象のシステム構成の定義の内容を匿名化した上で生成部に入力する付記２または付記３記載の協調計画システム。
（付記５）生成部は、生成された複数の部分的な手順を各計画システムの入力部にそれぞれ入力し、前記入力部には、入力された部分的な手順の実行に要する情報が他の計画システムから入力される付記２から付記４のうちのいずれか１項に記載の協調計画システム。
（付記６）入力部は、入力された部分的な手順に含まれる匿名化された情報を元の情報に変換する付記５記載の協調計画システム。
（付記７）管理対象のシステム構成の定義は、１つ以上の前記システム構成の要素群と要素間の関係性を含む定義情報であるコンポネントと、コンポネントが他のコンポネントと接続されるための点を示す定義情報であるポートと、ポート間の接続に関する定義情報であるワイヤとを含む高級なシステム構成定義であり、計画システムは、前記高級なシステム構成定義を要素群と要素間の関係性とで構成される低級なシステム構成定義に変換する変換部を含む付記１から付記６のうちのいずれか１項に記載の協調計画システム。
（付記８）計画システムが管理する高級なシステム構成定義は、他の計画システムが管理する高級なシステム構成定義内のポートの情報を含む付記７記載の協調計画システム。
（付記９）システム構成をそれぞれ管理する複数の計画システムを含み、複数のシステム構成の変更要求に対する変更手順を生成する協調計画システムにおいて実行される協調計画方法であって、前記複数の計画システムから入力された複数のシステム構成の定義を基に前記変更手順を生成し、生成された前記変更手順を各システム構成の要素に関する手順ごとに分割することによって複数の部分的な手順を生成し、実行が完了すると第２の部分的な手順に含まれる第２の手順の実行が開始される第１の手順を含む第１の部分的な手順に対して前記第２の部分的な手順を実行する計画システムに手順の完了を示す情報を入力する手順を前記第１の手順の後に追加し、前記第２の部分的な手順に対して前記第１の部分的な手順を実行する計画システムから前記手順の完了を示す情報が入力される手順を前記第２の手順の前に追加することを特徴とする協調計画方法。
（付記１０）システム構成をそれぞれ管理する複数の計画システムを含み、複数のシステム構成の変更要求に対する変更手順を生成するコンピュータにおいて実行される協調計画プログラムであって、前記コンピュータに、前記複数の計画システムから入力された複数のシステム構成の定義を基に前記変更手順を生成する第１生成処理、生成された前記変更手順を各システム構成の要素に関する手順ごとに分割することによって複数の部分的な手順を生成する第２生成処理、実行が完了すると第２の部分的な手順に含まれる第２の手順の実行が開始される第１の手順を含む第１の部分的な手順に対して前記第２の部分的な手順を実行する計画システムに手順の完了を示す情報を入力する手順を前記第１の手順の後に追加する第１追加処理、および前記第２の部分的な手順に対して前記第１の部分的な手順を実行する計画システムから前記手順の完了を示す情報が入力される手順を前記第２の手順の前に追加する第２追加処理を実行させるための協調計画プログラム。
（付記１１）複数のシステム構成の変更要求に対する変更手順を生成する生成部を備える協調計画装置であって、前記生成部は、システム構成をそれぞれ管理する複数の計画システムから入力された複数のシステム構成の定義を基に前記変更手順を生成し、生成された前記変更手順を各システム構成の要素に関する手順ごとに分割することによって複数の部分的な手順を生成し、実行が完了すると第２の部分的な手順に含まれる第２の手順の実行が開始される第１の手順を含む第１の部分的な手順に対して前記第２の部分的な手順を実行する計画システムに手順の完了を示す情報を入力する手順を前記第１の手順の後に追加し、前記第２の部分的な手順に対して前記第１の部分的な手順を実行する計画システムから前記手順の完了を示す情報が入力される手順を前記第２の手順の前に追加することを特徴とする協調計画装置。
１０ 協調計画システム
２０１〜２０Ｎ、１００、１００ａ 計画システム
３０ 生成部
１０１ 協調部
１０２ 計画部
１０３ 調整部
１０４ コンパイル部
１１０ 他の計画システム
１２０ 結合部
２００ 入出力装置
３００ 記憶装置
４００ 制御装置

Claims (10)

  1. システム構成をそれぞれ管理する複数の計画システムと、複数のシステム構成の変更要求に対する変更手順を生成する生成部とを含む協調計画システムであって、
    前記生成部は、
    前記複数の計画システムから入力された複数のシステム構成の定義を基に前記変更手順を生成し、
    生成された前記変更手順を各システム構成の要素に関する手順ごとに分割することによって複数の部分的な手順を生成し、
    実行が完了すると第２の部分的な手順に含まれる第２の手順の実行が開始される第１の手順を含む第１の部分的な手順に対して前記第２の部分的な手順を実行する計画システムに手順の完了を示す情報を入力する手順を前記第１の手順の後に追加し、
    前記第２の部分的な手順に対して前記第１の部分的な手順を実行する計画システムから前記手順の完了を示す情報が入力される手順を前記第２の手順の前に追加する
    ことを特徴とする協調計画システム。
  2. 計画システムは、管理対象のシステム構成の定義を加工した上で生成部に入力する入力部を含み、
    前記入力部は、
    複数のシステム構成の変更要求に基づいて前記管理対象のシステム構成の定義から変更対象の部分を抽出し、
    抽出された前記変更対象の部分を前記生成部に入力する
    請求項１記載の協調計画システム。
  3. 入力部は、抽出された変更対象の部分を１つ以上の強連結成分に分解した上で生成部に入力する
    請求項２記載の協調計画システム。
  4. 入力部は、管理対象のシステム構成の定義の内容を匿名化した上で生成部に入力する
    請求項２または請求項３記載の協調計画システム。
  5. 生成部は、生成された複数の部分的な手順を各計画システムの入力部にそれぞれ入力し、
    前記入力部には、入力された部分的な手順の実行に要する情報が他の計画システムから入力される
    請求項２から請求項４のうちのいずれか１項に記載の協調計画システム。
  6. 入力部は、入力された部分的な手順に含まれる匿名化された情報を元の情報に変換する
    請求項５記載の協調計画システム。
  7. 管理対象のシステム構成の定義は、１つ以上の前記システム構成の要素群と要素間の関係性を含む定義情報であるコンポネントと、コンポネントが他のコンポネントと接続されるための点を示す定義情報であるポートと、ポート間の接続に関する定義情報であるワイヤとを含む高級なシステム構成定義であり、
    計画システムは、前記高級なシステム構成定義を要素群と要素間の関係性とで構成される低級なシステム構成定義に変換する変換部を含む
    請求項１から請求項６のうちのいずれか１項に記載の協調計画システム。
  8. 計画システムが管理する高級なシステム構成定義は、他の計画システムが管理する高級なシステム構成定義内のポートの情報を含む
    請求項７記載の協調計画システム。
  9. システム構成をそれぞれ管理する複数の計画システムを含み、複数のシステム構成の変更要求に対する変更手順を生成する協調計画システムにおいて実行される協調計画方法であって、
    前記複数の計画システムから入力された複数のシステム構成の定義を基に前記変更手順を生成し、
    生成された前記変更手順を各システム構成の要素に関する手順ごとに分割することによって複数の部分的な手順を生成し、
    実行が完了すると第２の部分的な手順に含まれる第２の手順の実行が開始される第１の手順を含む第１の部分的な手順に対して前記第２の部分的な手順を実行する計画システムに手順の完了を示す情報を入力する手順を前記第１の手順の後に追加し、
    前記第２の部分的な手順に対して前記第１の部分的な手順を実行する計画システムから前記手順の完了を示す情報が入力される手順を前記第２の手順の前に追加する
    ことを特徴とする協調計画方法。
  10. システム構成をそれぞれ管理する複数の計画システムを含み、複数のシステム構成の変更要求に対する変更手順を生成するコンピュータにおいて実行される協調計画プログラムであって、
    前記コンピュータに、
    前記複数の計画システムから入力された複数のシステム構成の定義を基に前記変更手順を生成する第１生成処理、
    生成された前記変更手順を各システム構成の要素に関する手順ごとに分割することによって複数の部分的な手順を生成する第２生成処理、
    実行が完了すると第２の部分的な手順に含まれる第２の手順の実行が開始される第１の手順を含む第１の部分的な手順に対して前記第２の部分的な手順を実行する計画システムに手順の完了を示す情報を入力する手順を前記第１の手順の後に追加する第１追加処理、および
    前記第２の部分的な手順に対して前記第１の部分的な手順を実行する計画システムから前記手順の完了を示す情報が入力される手順を前記第２の手順の前に追加する第２追加処理
    を実行させるための協調計画プログラム。
JP2018546161A 2016-10-20 2017-08-16 協調計画システム、協調計画方法および協調計画プログラム Active JP6911865B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2016205841 2016-10-20
JP2016205841 2016-10-20
PCT/JP2017/029475 WO2018074042A1 (ja) 2016-10-20 2017-08-16 協調計画システム、協調計画方法および協調計画プログラム

Publications (2)

Publication Number Publication Date
JPWO2018074042A1 JPWO2018074042A1 (ja) 2019-08-08
JP6911865B2 true JP6911865B2 (ja) 2021-07-28

Family

ID=62018333

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2018546161A Active JP6911865B2 (ja) 2016-10-20 2017-08-16 協調計画システム、協調計画方法および協調計画プログラム

Country Status (3)

Country Link
US (1) US11657369B2 (ja)
JP (1) JP6911865B2 (ja)
WO (1) WO2018074042A1 (ja)

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5127104A (en) * 1986-12-29 1992-06-30 Dataflow Computer Corporation Method and product involving translation and execution of programs by automatic partitioning and data structure allocation
US7039597B1 (en) * 1998-06-05 2006-05-02 I2 Technologies Us, Inc. Method and system for managing collaboration within and between enterprises
US6615166B1 (en) * 1999-05-27 2003-09-02 Accenture Llp Prioritizing components of a network framework required for implementation of technology
US6704737B1 (en) * 1999-10-18 2004-03-09 Fisher-Rosemount Systems, Inc. Accessing and updating a configuration database from distributed physical locations within a process control system
US7738497B2 (en) * 2004-11-15 2010-06-15 Sap, Ag System and method for dynamically modifying synchronized business information server interfaces
US7343364B2 (en) * 2005-02-04 2008-03-11 Efunds Corporation Rules-based system architecture and systems using the same
US20080256549A1 (en) * 2007-04-10 2008-10-16 International Business Machines Corporation System and Method of Planning for Cooperative Information Processing
US8429645B2 (en) * 2007-08-14 2013-04-23 International Business Machines Corporation Method for optimizing migration of software applications to address needs
US8416811B2 (en) * 2008-04-10 2013-04-09 International Business Machines Corporation Coordinated timing network having servers of different capabilities
JP5177223B2 (ja) * 2008-06-13 2013-04-03 富士通株式会社 情報処理装置、情報処理プログラム及び方法
US8713146B2 (en) * 2009-03-27 2014-04-29 Ebay Inc. Change management automation tool
US20120245972A1 (en) * 2011-03-25 2012-09-27 Tradecard Inc. Providing access to future exception information in a supply plan collaboration system
US9524179B2 (en) * 2011-05-05 2016-12-20 Microsoft Technology Licensing, Llc Virtual-machine-deployment-action analysis
JP5742630B2 (ja) * 2011-09-28 2015-07-01 富士通株式会社 情報処理方法及び装置
JP5966696B2 (ja) * 2012-07-05 2016-08-10 富士通株式会社 制御プログラム、情報処理装置およびシステム
US9557988B2 (en) * 2012-09-07 2017-01-31 Inadev Corporation Workflow-based application generator
AU2013359762B2 (en) * 2012-12-10 2016-02-18 Viditeck Ag Rules based data processing system and method
WO2015068231A1 (ja) * 2013-11-07 2015-05-14 株式会社 日立製作所 計画連携システムおよび計画連携方法
US20150324211A1 (en) * 2014-05-09 2015-11-12 Vanderbilt University Change planning system, change planning method, and change planning program
US20160217423A1 (en) * 2015-01-23 2016-07-28 Magnan Technologies, Llc Systems and methods for automatically generating application software

Also Published As

Publication number Publication date
WO2018074042A1 (ja) 2018-04-26
US20200051027A1 (en) 2020-02-13
US11657369B2 (en) 2023-05-23
JPWO2018074042A1 (ja) 2019-08-08

Similar Documents

Publication Publication Date Title
Zuiderwijk et al. A coordination theory perspective to improve the use of open data in policy-making
AU2014304231B2 (en) Managing a succession of deployments of an application programming interface (API) server configuration in the software lifecycle development
CN102224496B (zh) 公共配置应用程序编程接口
CN103701633B (zh) 对分布式搜索SolrCloud进行可视化集群应用搭建和维护的***
Ujcich et al. Provenance for intent-based networking
CN113067900B (zh) 智能合约的部署方法及装置
Mazur et al. Analysis of possible SDN use in the rapid prototyping process as part of the Industry 4.0
US20110035229A1 (en) Method and system for incorporating service-oriented automation components of a manufacturing facility into a flexible it corporate architecture
García-Sánchez et al. Service oriented evolutionary algorithms
Liu Some complexity results for the soundness problem of workflow nets
Autili et al. Model-driven adaptation of service choreographies
Sharma et al. Intent negotiation framework for intent-driven service management
JP6911865B2 (ja) 協調計画システム、協調計画方法および協調計画プログラム
CN117555522A (zh) 一种用于多云管理平台的云管总线
Wang et al. Federated MapReduce to transparently run applications on multicluster environment
Sevegnani et al. Towards a bigraphical encoding of actors
CN101960420B (zh) 在计算环境中管理资源的方法
Bucchiarone et al. Towards a domain specific language for engineering collective adaptive systems
CN114035923A (zh) 一种基于DolphinScheduler的任务调度方法、***、设备以及介质
Papoutsakis et al. CIRCE: architectural patterns for circular and trustworthy by-design IoT orchestrations
JP2019205080A (ja) 変換装置、および、変換プログラム
US20150193105A1 (en) Interaction Protocol for Interacting Computer Systems
Cabri et al. Comparing service-oriented computing and agent-oriented programming towards integration
CN113608832A (zh) 一种应用部署方法、***、设备以及介质
CN118300845A (zh) 云原生访问控制规则生成方法及***

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20190411

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20200702

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20210608

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20210621

R150 Certificate of patent or registration of utility model

Ref document number: 6911865

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150