(第1の実施の形態)
[構成の説明]
以下、本発明の実施形態を、図面を参照して説明する。図1は、本発明による計画システムの第1の実施形態の構成例を示すブロック図である。図1に示すように、本実施形態の計画システム100は、協調部101と、計画部102と、調整部103とを含む。
図1に示すように、協調部101は、計画部102および調整部103と、通信ネットワーク等を介して通信可能に接続されている。また、計画部102は、調整部103および計画システム100の外部の入出力装置200と通信ネットワーク等を介して通信可能に接続されている。
また、図1に示すように、協調部101は、他の計画システム110や計画システム100の外部の結合部120と通信ネットワーク等を介して通信可能に接続されている。また、他の計画システム110は、協調部101が通信可能に接続されている同一の結合部120と通信ネットワーク等を介して通信可能に接続されている。また、計画システム100の各構成要素は、記憶装置300および制御装置400と通信ネットワーク等を介して通信可能に接続されている。
協調部101は、計画システム100の外部の要素との協調動作を実行する機能を有する。協調部101は、計画部102や調整部103からの依頼に基づいて、通信可能な任意の他の計画システム110、および結合部120との協調動作を実行する。
計画部102は、システム構成の変更手順を生成する機能を有する。計画部102は、利用者が入力したシステム構成の変更要求を受け付け、要求されたシステム構成の変更を実現可能なシステム構成の変更手順を生成する。また、計画部102は、利用者に生成された変更手順を返答する。
調整部103は、システム構成定義を調整する機能を有する。調整部103は、記憶装置300から読み込んだシステム構成定義を調整し、調整されたシステム構成定義を計画部102に入力する。
記憶装置300には、計画システム100が管理するシステム構成定義が記憶されている。また、記憶装置300には、情報が記録されるための記憶領域が生成される。なお、記憶領域が生成される場所は、記憶装置300に限定されない。
制御装置400は、計画部102が生成したシステム構成の変更手順に従ってシステム構成の変更処理を実行する機能を有する。
複数の図1に示す計画システム100で構成されるシステムの例を図2に示す。図2は、複数の計画システムで構成されるシステムの構成例を示す説明図である。
各計画システムは、それぞれの結合部(図示せず)を介して他の計画システムと通信可能に接続されている。また、各計画システムの記憶装置300には、システム構成定義が記憶されている。
図2に示す計画システムが管理するシステム構成定義は、他の計画システムが管理するシステム構成定義と関連している。具体的には、図2に示す点線の矢印は、システム構成定義間の関係性を表現している。以下、計画システムにより管理されるシステム構成定義の範囲を、計画システムの管理ドメインと呼ぶ。
本実施形態のシステム構成定義は、状態要素と呼ばれる構成要素の集合で表現される。状態要素には、自身が取り得る状態や、実行可能な状態遷移を示す各情報が含まれる。また、状態要素には、自身の現在状態、自身の目的状態、および他の状態要素との関係性を示す各情報が適宜含まれる。
図2に示すシステム構成定義内の実線の矩形が状態要素を表す。矩形の左上の文字が状態要素の名称である。また、状態要素内の楕円が、状態要素の取り得る状態を表す。楕円内の文字が状態の名称である。また、状態間の矢印が状態遷移を表す。また、破線の楕円は現在状態を、黒色の楕円は目的状態をそれぞれ表す。また、状態遷移と他の状態要素内の状態とを結ぶ点線の矢印が、他の状態要素との関係性を表す。
図3は、システム構成定義の一例を示す説明図である。図3に示すシステム構成定義は、図2に示す管理ドメインD2内のシステム構成定義である。
図3に示す例では、情報の表現形式としてJSON(JavaScript(登録商標) Object Notation)形式が用いられている。以下、本明細書ではテキスト形式で情報を表現する場合、表現形式にJSON形式を用いる。なお、システム構成定義は、JSON形式以外の表現形式で表現されてもよい。
図3には、状態要素として"e1"と"e2"が記載されている。図3に示すように、状態要素"e1"は、取り得る状態として"s1"と"s2"を持つ。また、状態要素"e1"は、実行可能な状態遷移として"s1 からs2への遷移" (図3に示す"s1->s2")と、逆向きの遷移である"s2 からs1への遷移" (図3に示す"s2->s1")をそれぞれ持つ。
また、図3に示すように、状態要素"e1"の現在状態および目的状態は、共に状態"s2"である。また、状態要素"e1"は、他の状態要素との関係性を示す情報として、2つの事前状態制約を持つ。
本実施形態の事前状態制約は、システム構成定義間の関係性を示す情報の例である。事前状態制約は、状態遷移が実行されるためには別の状態要素が所定の状態であることを要するという制約である。事前状態制約が用いられると、例えば、仮想マシン(VM)において稼働するサービスがある場合、サービスの状態を" 稼働状態" に遷移させるためにはVMの状態が" 稼働状態" であることを要するという関係性が表現される。
特許文献2に記載されている手法は、1つ以上の状態要素の現在状態と目的状態が異なる場合、事前状態制約を満たしつつ全ての状態要素の状態を現在状態から目的状態へと遷移させるシステム構成の変更手順を生成できる。上記のVMとサービスの例では、最初にVMを起動し、続いてサービスを起動するという順序性を持つシステム構成の変更手順が生成される。
また、本実施形態のシステム構成定義では、他の管理ドメイン内のシステム構成定義に含まれる状態要素に対しても関係性が指定される。図3に示す例では、状態要素"e1"の状態遷移"s1->s2"は、管理ドメインDN内の状態要素"e1"の状態"s1"に対して事前状態制約を指定している。また、状態要素"e1"の状態遷移"s2->s1"は、同じ管理ドメインD2内の状態要素"e2"の状態"s1"に対して事前状態制約を指定している。
なお、他の管理ドメイン内の状態要素は、図3に示す"DN::e1"のように、管理ドメインを示すidが付与されることによって表現されてもよい。以下、本明細書では管理ドメイン内の情報を表現する場合、管理ドメイン内の情報と管理ドメインを示すidを"::"で繋ぐ記載方法を用いる。
なお、動作の都合上、本実施形態のシステム構成定義間の関係性を示す情報は、各システム構成定義内の両方の状態要素に保持される。例えば、事前状態制約が指定されている側の状態要素には、図3に示すように指定された事前状態制約が" 被事前状態制約" として記録される。
図4は、システム構成の変更要求の一例を示す説明図である。図4に示すように、管理ドメインにおいて受け付けられるシステム構成の変更要求には、管理ドメイン内の状態要素の新たな目的状態が指定される。
例えば、所定の時点におけるシステム構成定義が図2に示す内容であり、管理ドメインD1において図4に示すシステム構成の変更要求が受け付けられた場合を考える。図2に示すように、状態要素"D1::e1"の現在状態は状態"s1"である。図4に示すシステム構成の変更要求では目的状態が状態"s2"に指定されているため、状態要素"D1::e1"には、状態"s2"に遷移することが求められる。
図3を参照すると、状態要素"D1::e1"が状態"s2"に遷移する場合、事前状態制約が満たされることが条件になる。具体的には、状態要素"D2::e1"に状態"s1"に遷移することが求められる。さらに、状態要素"D2::e1"が状態"s1"に遷移するために、状態要素"D2::e2"に状態"s1"に遷移することが求められる。
また、図2に示すように状態要素"D2::e1"の目的状態が状態"s2"であるため、状態要素"D2::e1"には、状態"s1"に遷移した後で再度状態"s2"に遷移することが求められる。なお、状態要素"D2::e2"には目的状態が指定されていないため、状態要素"D2::e2"は、状態"s1"に遷移した後に他の状態に遷移しなくてよい。
なお、図3を参照すると、状態要素"D2::e1"から状態要素"DN::e1"の状態"s1"に事前状態制約が指定されている。しかし、図2に示すように、状態要素"DN::e1"の現在状態が状態"s1"であるため、図4に示す変更要求に関して状態要素"DN::e1"に事前状態制約の影響は及ばないと考えられる。
本実施形態では、例えば図5に示すシステム構成の変更手順が生成される。図5は、第1の実施形態で生成されるシステム構成の変更手順の一例を示す説明図である。
図5に示すシステム構成の変更手順には、図5(a)に示す管理ドメインD1における変更手順と、図5(b)に示す管理ドメインD2における変更手順が含まれる。すなわち、本実施形態で生成される変更手順は、管理ドメインごとに分けて表現される。
また、本実施形態で生成される変更手順には、作業が行われる管理ドメインが変更される際に作業を開始させるための手順が加えられている。図5(b)に示す"call X"は、一連の作業におけるポイント"X" まで作業が完了したことを管理ドメインD1内の計画システムに通知する手順である。ポイント"X" まで作業が完了した後、"call X"が実行される。図5(a)に示す"call Y"も"call X"と同様の手順である。
また、図5(a)に示す"wait X"は、管理ドメインD1内の計画システムがポイント"X" まで作業が完了したことの通知を待ち受ける手順である。"wait X"が実行された後、ポイント"X" 以降の作業が実行される。図5(b)に示す"wait Y"も"wait X"と同様の手順である。
すなわち、図5は、最初に状態要素"D2::e2"を状態"s2"から状態"s1"へ遷移させ、次いで状態要素"D2::e1"を状態"s2"から状態"s1"へ遷移させ、次いで状態要素"D1::e1"を状態"s1"から状態"s2"へ遷移させ、最後に状態要素"D1::e1"を状態"s1"から状態"s2"へ再度遷移させるという一連の手順を示す。
図5に示すようなシステム構成の変更手順が各管理ドメイン内に用意されれば、各計画システムが担当するシステム構成の変更手順を実行することによって、全体的に整合が保たれたまま、一連のシステム構成の変更作業が実行される。
図5に示すシステム構成の変更手順は、以下に説明する概念に基づいて生成される。例えば、異なる2つの管理ドメインDAおよび管理ドメインDBと、管理ドメインDAで管理されるシステムSA、および管理ドメインDBで管理されるシステムSBを想定する。システムSAは、システムSBとの間に依存関係を有する。
システムSAに対するシステム構成の変更要求の影響がシステムSBに及ぶ場合を考える。上記の場合、システムSAに関するシステム構成の変更手順PAは、管理ドメインDA内でのみ生成されれば充分であると考えられる。同様に、システムSBに関するシステム構成の変更手順PBは、管理ドメインDB内でのみ生成されれば充分であると考えられる。
さらに、各管理ドメインにおいて変更手順の内容が承認された上で、システムSAとシステムSBが協調的に動作することによって全ての作業が完遂されればよいと考えられる。本実施形態では、上記の概念に基づいてシステム構成の変更手順が生成される。
なお、システム構成の変更手順を生成する際、本実施形態の計画システム100は、状態要素自体を管理ドメイン間で交換しない。状態要素群を一箇所に集めることが避けられない手順探索処理を実行する場合、計画システム100は、外部の結合部120を用いる。その理由は、他の計画システム110に開示される状態要素の内容を最低限にするためである。また、結合部120に集められる状態要素群の数を最小限に留めるために、計画システム100は、グループ分割等の前処理を実行する。
[動作の説明]
以下、本実施形態の計画システム100の動作を図6、図9、図12、および図22を参照して説明する。図6は、第1の実施形態の計画システム100による変更手順の生成処理の全体動作を示すフローチャートである。
本実施形態の計画システム100が実行する変更手順の生成処理では、複数の管理ドメイン内のシステム構成定義が処理の対象になる。計画システム100は、他の管理ドメイン内の計画システム群と協調して処理を進める。
計画部102は、入出力装置200を介して利用者からシステム構成の変更要求を受け付ける。受け付けた後、計画部102は、システム構成の変更要求が一意に特定される変更要求idを生成する(ステップS1100 )。
次いで、計画部102は、受け付けられたシステム構成の変更要求に関する情報を生成された変更要求idと対応付けて記録するための記憶領域を記憶装置300に生成する(ステップS1200 )。計画部102は、生成された記憶領域にシステム構成の変更要求に関する情報を変更要求idと対応付けて記録する。
次いで、計画部102は、ステップS1100 で生成された変更要求idを調整部103に通知する。以下、システム構成の変更要求に関する情報は、常に変更要求idと共に記憶領域に記録される。変更要求に関する情報が参照される際、変更要求idが参照キーになる。
変更要求idが通知された後、調整部103は、記憶装置300からシステム構成定義を読み込む。次いで、調整部103は、読み込まれたシステム構成定義における通知された変更要求idが示す変更要求の影響範囲を抽出する(ステップS1300 )。
各計画システムが管理するシステム構成定義は、多くの状態要素群で構成されている可能性がある。すなわち、システム構成定義全体が考慮の対象になると、手順計画の実行が困難になる恐れがある。本実施形態では、調整部103が影響範囲を抽出することによって、システム構成の変更に関係する部分だけを基に変更手順が生成される。
例えば、管理ドメインD1内の計画システムが図4に示すシステム構成の変更要求を受け付けた上記の例の場合、調整部103は、図2に示す状態要素"DN::e1"が影響範囲外の状態要素であると判断し、状態要素"DN::e1"を影響範囲に含めない。
次いで、調整部103は、システム構成定義から抽出された影響範囲を、計画部102による手順探索処理が一括で行われるグループごとに分割する(ステップS1400 )。調整部103は、生成された複数のグループを計画部102に入力する。
手順探索処理には、一度に処理される状態要素が増えると加速度的に処理負荷が高くなるという問題がある。また、複数の管理ドメイン内のシステム構成定義に対する手順探索処理が実行されるためには、システム構成定義が一箇所に集められることが求められる。よって、集められるシステム構成定義の範囲を最小化することがセキュリティ上重要である。
具体的な分割方法として、例えば特許文献3に記載されている手法と同様にシステム構成定義を、システム構成定義内の状態要素がノード、状態要素間の関係性がエッジであるグラフと捉えた上で、グラフを強連結成分ごとに分割する方法がある。
次いで、計画部102は、入力された全てのグループに対して手順探索処理を実行する。計画部102は、手順探索処理の実行結果として生成される部分的な手順を繋ぎ合わせることによって、システム構成の変更手順全体を生成する(ステップS1500 )。なお、図6に示すように、ステップS1500 の処理全体をプランニングと呼ぶ。システム構成の変更手順を生成した後、計画システム100は、変更手順の生成処理を終了する。
図7は、第1の実施形態の計画システム100による変更手順の生成処理の具体例を示す説明図である。図7に示す矩形は状態要素を表し、点線の矢印は事前状態制約を表している。矩形内の文字が状態要素の名称である。
以下、変更手順の生成処理を構成する副処理である、ステップS1300 の影響範囲抽出処理、ステップS1400 のグループ分割処理、およびステップS1500 のプランニングを図7を参照してそれぞれ説明する。
以降の説明を簡略化するために、各副処理で多用される一般的な深さ優先探索処理を説明する。深さ優先探索処理は、ノードとエッジで構成されたグラフが与えられグラフ内の1つのノードが指定された時に、指定されたノードを起点として到達可能な全てのノードを発見する処理の1つである。深さ優先探索処理では、新たに発見された到達可能なノードから更に到達可能な他のノードが優先的に探索される。
図8は、深さ優先探索処理の一例を示す説明図である。図8に示す円はノードを表す。円内の文字がノードの名称である。また、図8に示すノード同士を結ぶ矢印は、エッジを表す。
図8(a)は、ツリーにおける深さ優先探索処理を示す。図8(a)に示すツリー、およびノード"a" が指定された場合、深さ優先探索処理では、最初にノード"a" から到達可能なノード"b" が発見される。次いで、ノード"b" から更に到達可能なノード"d" が発見される。
図8(a)に示すようにノード"d" から更に到達可能なノードは存在しないため、ノード"d" が発見された後、ノード"b" から到達可能な別のノードであるノード"e" が発見される。ノード"e" から更に到達可能なノードは存在せず、またノード"b" から到達可能な別のノードも残っていないため、ノード"e" が発見された後、ノード"a" から到達可能な別のノードであるノード"c" が最後に発見される。
図8(a)に示す点線の矢印は、上記の基本的な深さ優先探索の軌跡を示す。なお、深さ優先探索処理の対象は、図8(a)に示すようなツリー以外の一般的なグラフでもよい。ただし、一度発見されたノードは探索の対象から外されるため、探索結果だけが着目されると、深さ優先探索処理では常にツリーが構成される。
図8(b)は、グラフにおける深さ優先探索処理を示す。図8(b)に示すグラフにおいて、ノード"d" の次にノード"b" が探索されようとしても、既にノード"b" は発見されているため、結果的に探索されない。
深さ優先探索処理が複数の管理ドメインに渡って行われる場合、探索の開始時に探索作業が一意に特定される探索idが生成される。ノードが発見された際、生成された探索idが示す探索作業においてノードが既に発見されているか否かが確認される。
管理ドメインを跨るエッジが辿られる際、探索元の管理ドメイン内の計画システムは、探索idの下でどのノードからどのノードに向けて探索が進められるかを探索先の管理ドメイン内の計画システムに通知すればよい。
また、管理ドメインを跨るエッジが逆方向に辿られる際、探索先の管理ドメイン内の計画システムは、探索idの下でどのノードからどのノードに向けて探索が戻されるかを探索元の管理ドメイン内の計画システムに通知すればよい。
また、管理ドメイン内のノードから他の管理ドメイン内のノードに向けて探索が進められようとした際に探索先のノードが既に探索済みであった場合、探索先の管理ドメイン内の計画システムは、ノードが探索済みである旨を単に返答すればよい。
図8(c)は、管理ドメインを跨るグラフにおける深さ優先探索処理を示す。図8(c)に示す例において、例えばノード"a,b,d" が探索された後にノード"d" からノード"b" に向けて探索を進めようとする際、管理ドメインD2内の計画システムは、管理ドメインD1内の計画システムに対して探索を依頼する。
探索を依頼された管理ドメインD1内の計画システムは、ノード"b" が探索済みであることを管理ドメインD2内の計画システムに返答する。返答を受けた管理ドメインD2内の計画システムは、ノード"f" に向けてさらに探索を進めればよい。
以下の副処理の説明では、深さ優先探索が用いられる場合であっても上述した基本的な動作の説明を省略する。副処理の説明の中で、処理の種類に応じる箇所を説明することによって深さ優先探索処理の内容を示す。
処理の種類に応じる箇所は、例えばノードとみなされる対象、およびエッジとみなされる対象である。また、処理の種類に応じる箇所は、ノードが最初に発見された時に実行される処理や、ノードから探索可能な他のノードが全て発見されて探索が戻される際に実行される処理である。
また、処理の種類に応じる箇所は、管理ドメインを跨いで探索が進められる際に管理ドメイン内の計画システム間で送受信される通信内容や、送受信の前後に実行される処理等である。
最初に、ステップS1300 の影響範囲抽出処理を図9を参照して説明する。図9は、第1の実施形態の調整部103による影響範囲抽出処理の動作を示すフローチャートである。
影響範囲抽出処理において、調整部103は、変更を要する状態要素を起点に、状態要素との関係性に従って付随的に変更される状態要素や、付随的に変更される状態要素を起因として連鎖的に変更される全ての状態要素を発見する。
変更される全ての状態要素を発見するために、調整部103は、図9に示す影響範囲抽出処理を行う。システム構成の変更要求が受け付けられた管理ドメイン内の調整部103は、システム構成の変更要求で目的状態が指定された状態要素のうち、指定された目的状態が記憶装置300に記録された現在状態と異なる状態要素を、変更を要する状態要素とみなす(ステップS1310 )。次いで、調整部103は、変更を要する状態要素が影響範囲に含まれることを記録する。
次いで、調整部103は、ステップS1310 で発見された状態要素の変更が影響する他の状態要素を探索する。調整部103は、ステップS1310 で発見された各状態要素のうち、変更が影響する他の状態要素が未探索の状態要素が残っているか否かを確認する(ステップS1320 )。
未探索の状態要素が残っていない場合(ステップS1320 におけるYes )、調整部103は、影響範囲抽出処理を終了する。
未探索の状態要素が残っている場合(ステップS1320 におけるNo)、調整部103は、未探索の状態要素を1つ取り出す。次いで、調整部103は、取り出された状態要素を起点とした深さ優先探索処理を実行することによって、変更が影響する他の状態要素を発見する(ステップS1330 )。
ステップS1330 で実行される深さ優先探索処理では、状態要素がノードとみなされる。また、ノードである状態要素が有する関係性が他の状態要素に影響を及ぼす可能性がある場合、関係性がエッジとみなされる。
状態要素が有する関係性が事前状態制約であれば、関係性は、指定された状態要素の状態が状態要素の現在状態と異なる場合に影響を及ぼす可能性があると判断される。その理由は、上述したような事前状態制約は、状態遷移が実行されるために指定された状態要素が現在状態と異なる状態に遷移することを要すると示すためである。
また、ステップS1330 で実行される深さ優先探索処理においてノードが発見された際、調整部103は、発見されたノードに相当する状態要素を、ノードが存在する管理ドメインにおける影響範囲に追加する。深さ優先探索処理を終了した後、調整部103は、再度ステップS1320 の処理を行う。
例えば、図7(a)に示すシステム構成定義から影響範囲を抽出する処理を考える。管理ドメインD1内の計画システム100がシステム構成の変更要求を受け付けた後、状態要素"a" 、状態要素"h" 、および状態要素"x" の変更が確定されたとする。なお、図7に示す黒色の状態要素は、変更が確定された状態要素である。
調整部103は、状態要素"a" を起点とした深さ優先探索処理を実行することによって、変更が影響する状態要素として例えば状態要素"a,b,c,d,e,f,g,h,i" を発見する。深さ優先探索処理が実行された段階で、未探索の状態要素である状態要素"x" が残っている。
次いで、調整部103は、状態要素"x" を起点とした深さ優先探索処理を実行することによって、変更が影響する状態要素として状態要素"x,y" を発見する。2回目の深さ優先探索処理が実行された段階で未探索の状態要素は残っていないため、調整部103は、影響範囲抽出処理を終了する。図7(b)に示す実線の枠が、最終的に抽出された影響範囲を表す。
図10は、影響範囲抽出処理中の管理ドメインごとの記録情報の一例を示す説明図である。図10は、管理ドメインD2における影響範囲の記録情報の例を示す。図10に示すように、影響範囲に含まれる状態要素として、状態要素"b,f,g,y" が記録されている。影響範囲に含まれる状態要素は、状態要素が存在する各管理ドメインにおいて記録されていればよい。
次に、ステップS1400 のグループ分割処理を説明する。上記の通り、グループ分割処理ではシステム構成定義が、システム構成定義内の状態要素がノード、状態要素間の関係性がエッジであるグラフと捉えられる。グループ分割処理において、調整部103は、グラフを複数の強連結成分に分解する。
強連結成分の分解方法は、複数存在する。本実施形態では、複数の方法のうちの1つの方法が用いられた処理例を示す。以下、本実施形態で用いられる強連結成分の分解方法を説明する。なお、本実施形態で用いられる強連結成分の分解方法は、以下に示す方法に限定されない。
図11は、強連結成分への分解処理の一例を示す説明図である。図11に示す円はノードを表す。円内の文字がノードの名称である。また、図11に示すノード同士を結ぶ矢印は、エッジを表す。図11に示す手法によれば、深さ優先探索処理が2回実行されることによって、グラフ全体が複数の強連結成分に分解される。
1回目の深さ優先探索処理では、適当なノードから探索が実行され、探索が開始されたノードからの探索ステップが最も深いノードから順に番号が付与される。例えば、図11(a)に示すグラフが与えられ、ノード"a" が探索の開始ノードに選択されたとする。
1回目の深さ優先探索処理で"a","b","d","e","f" の順にノードが辿られた後、ノード"f" の先にノードは発見されない。よって、ノード"f" に番号「1 」が付与される。次いで、ノード"g" の先にノードは発見されないため、ノード"g" に番号「2 」が付与される。
次いでノード"e" に探索が戻された後、ノード"e" の先にノード"f,g" 以外の新たなノードは発見されないため、ノード"e" に番号「3 」が付与される。以下、同様に処理が進められると、図11(b)に示すように各ノードに番号が付与される。図11に示すノードの近傍の数字が、ノードに付与された番号である。なお、図11(b)に示す点線の矢印は、探索の軌跡を表す。
次に、2回目の深さ優先探索処理では、エッジの向きが逆向きに変更された上で、付与された番号が最大のノードから探索が開始される。探索された際に到達可能なノード群が1つの強連結成分を形成する。
例えば、最大の番号である番号「7 」が付与されたノード"a" から探索を開始すると、エッジの向きが逆になったことに注意すれば、調整部103は、"a,c,b" の3つのノードがノード"a" から到達可能なノードであることが分かる。すなわち、図11(c)に示すように、ノード群"a,c,b" は、強連結成分を形成する。図11に示す破線の楕円が、強連結成分を表す。
次いで、強連結成分を形成すると判定されたノードが除外された上で、現時点で最大の番号である番号「4 」が付与されたノード"d" から探索を再度開始すると、調整部103は、"d,e" の2つのノードがノード"d" から到達可能なノードであることが分かる。すなわち、図11(d)に示すように、ノード群"d,e" は、強連結成分を形成する。同様に、ノード"f" のみで形成された強連結成分と、ノード"g" のみで形成された強連結成分が発見される。
ステップS1400 のグループ分割処理では、複数の管理ドメイン内の計画システムが、上述したような強連結成分への分解処理を協調して実行する。以下、ステップS1400 のグループ分割処理の動作を説明する。図12は、第1の実施形態の調整部103によるグループ分割処理の全体動作を示すフローチャートである。
調整部103は、最初に順方向の深さ優先探索処理を実行することによって、各状態要素に番号を付与する(ステップS1410 )。次いで、調整部103は、逆方向の深さ優先探索処理を実行することによって、状態要素群を複数の強連結成分に分解する(ステップS1420 )。複数の強連結成分に分解した後、調整部103は、グループ分割処理を終了する。
以下、グループ分割処理を構成する副処理を説明する。最初に、ステップS1410 の順方向の深さ優先探索処理を説明する。図13は、第1の実施形態の調整部103による順方向の深さ優先探索処理の動作を示すフローチャートである。図13に示す処理は、グループ分割で使用される番号を付与する処理である。
調整部103は、全ての状態要素に番号が付与されるように、未探索の状態要素が残っているか否かを確認する(ステップS1411 )。未探索の状態要素が残っていない場合(ステップS1411 におけるYes )、調整部103は、順方向の深さ優先探索処理を終了する。
未探索の状態要素が残っている場合(ステップS1411 におけるNo)、調整部103は、未探索の状態要素を1つ取り出す。次いで、調整部103は、取り出された状態要素を起点とした深さ優先探索処理を実行することによって、各状態要素に番号を付与する(ステップS1412 )。
ステップS1412 における深さ優先探索処理では、状態要素がノード、状態要素間の関係性がエッジとみなされる。また、各状態要素の探索が終了した後、調整部103は、探索された状態要素に番号を付与する以外に、管理ドメインにおける最大番号を記録する。深さ優先探索処理を終了した後、調整部103は、再度ステップS1411 の処理を行う。
例えば、図7(b)に示す実線の枠内のシステム構成定義に対して、調整部103が状態要素"a" を起点とした深さ優先探索処理を実行した場合、図14に示すように各状態要素に番号が付与される。
図14は、グループ分割に用いられる番号が付与された状態要素の一例を示す説明図である。例えば、状態要素"a" であれば「a:9 」と記載されているため、番号「9 」が付与されている。また、二重枠で表現された状態要素は、深さ優先探索処理での起点の状態要素である。
図15は、番号付与処理中の管理ドメインごとの記録情報の一例を示す説明図である。図15は、管理ドメインD2において記録されている番号付与に関する情報の一例を示す。ステップS1410 の処理が終了した時点で、図15に示すような情報が記録される。図15に示すように、状態要素"b,f,g" それぞれに付与された番号が記録されている。また、管理ドメインD2における最大番号である番号「6 」と、最大番号が付与された状態要素"g" とが記録されている。
図16は、番号付与の処理において協調部間で送受信される通信内容の一例を示す説明図である。図16(a)は、状態要素"D2::g" から状態要素"D1::h" へ向けて探索を進める際に管理ドメインD2内の計画システムから送信される要求メッセージを示す。
また、図16(b)は、管理ドメインD1内の計画システムから送信される、図16(a)に示す要求メッセージに対する返答メッセージを示す。管理ドメインを跨ぐ探索が行われる際に現時点での各管理ドメインの最大番号が双方に通知されることによって、全体的に連続した番号が付与される。
次に、ステップS1420 の逆方向の深さ優先探索処理を説明する。図17は、第1の実施形態の調整部103による逆方向の深さ優先探索処理の動作を示すフローチャートである。図17に示す処理は、グループ分割として状態要素群を複数の強連結成分に分解する処理である。
調整部103は、状態要素群を複数の強連結成分に分解するために、未探索の状態要素が残っているか否かを確認する(ステップS1421 )。未探索の状態要素が残っていない場合(ステップS1421 におけるYes )、調整部103は、逆方向の深さ優先探索処理を終了する。
未探索の状態要素が残っている場合(ステップS1421 におけるNo)、調整部103は、未探索の状態要素のうち最大番号が付与された状態要素を起点とした逆向きの深さ優先探索処理を実行することによって、強連結成分を抽出する(ステップS1422 )。
ステップS1421 〜ステップS1422 において調整部103は、未探索の状態要素や最大番号が付与された状態要素を、関連する複数の管理ドメイン全体から発見する。上記の処理を行うために、各管理ドメイン内の計画システムは、システム構成定義間の関係性の観点で関連する管理ドメインの情報を管理してもよい。
例えば、管理ドメインD1内の計画システムは、関連する管理ドメインとして管理ドメインD2の情報を管理してもよい。また、管理ドメインD2内の計画システムは、関連する管理ドメインとして管理ドメインD1の情報と管理ドメインD3の情報を管理してもよい。また、管理ドメインD3内の計画システムは、関連する管理ドメインとして管理ドメインD2の情報を管理してもよい。
管理対象の情報は、例えばステップS1330 の深さ優先探索処理において、計画システムが他の管理ドメインとの関係性を発見して探索要求を送る際や、他の管理ドメインから探索要求を受け付けた際に、相手の管理ドメインを記録することによって得られる。
関連する管理ドメインの情報が示す状態要素は全体としてグラフを形成するため、計画システムがグラフに対して深さ優先探索処理を実行することによって、未探索の状態要素や最大番号が付与された状態要素が発見される。
すなわち、ノードに相当する各管理ドメイン内の計画システムが、把握している未探索の状態要素の有無の情報を探索元の計画システムに返すことによって、全体としての未探索の状態要素の有無が認識される。また、ノードに相当する各管理ドメイン内の計画システムが、把握している最大番号を探索元の計画システムに返すことによって、全体としての最大番号が取得される。
ステップS1422 では、第1の深さ優先探索処理が実行されることによって、最大番号が付与された状態要素が発見される。また、第1の深さ優先探索処理において、強連結成分分解が行われるための第2の深さ優先探索処理がノードごとの処理として実行される。
ステップS1422 における深さ優先探索処理では、状態要素がノード、状態要素間の関係性を表す矢印の向きが反対の矢印がエッジとみなされる。また、調整部103は、探索の開始時に管理ドメインにおける新規のグループidを生成し、管理ドメインの情報として記録する。
探索によりノードが発見された際、調整部103は、発見されたノードに相当する状態要素を生成されたグループidが示すグループのメンバとして記録する。記録することによって管理ドメインにおける最大番号が変化する場合、調整部103は、最大番号を更新する。
また、他の管理ドメインへ探索が及んだ際に他の管理ドメインからメンバが新たにグループに参加すれば、調整部103は、他の管理ドメインをグループの関連ドメインとして記録する。
管理ドメインを跨ぐ探索を要求する際、調整部103は、メンバの探索中のグループのidを計画システムに通知する。要求を受けた管理ドメイン内の計画システムは、通知されたidが示すグループを自身のグループとして記録する。さらに、計画システムは、要求元の管理ドメインを記録されたグループの関連ドメインとして記録した上で、継続して探索を実行する。また、計画システムは、発見された状態要素を記録されたグループのメンバとして記録する。
図18は、グループ分割に用いられる番号が付与された状態要素の他の一例を示す説明図である。図14に示す状態要素間の矢印の向きと、図18に示す状態要素間の矢印の向きは反対である。例えば、図18に示す状態要素群に対して状態要素"a" を起点とした深さ優先探索処理を開始する際、管理ドメインD1内の調整部103は、新規のグループidとして"D1::G1"を生成し、記録する。
図18に示す例に対する管理ドメイン内の記録情報の一例を図19に示す。図19は、強連結成分分解処理中の管理ドメインごとの記録情報の一例を示す説明図である。図19は、逆方向の深さ優先探索処理が実行された際の記録情報を示す。図19(a)は、管理ドメインD1内の記録情報を示す。また、図19(b)は、管理ドメインD2内の記録情報を示す。
図19(a)を参照すると、状態要素"a,h" が探索された結果として、グループ"D1::G1"のメンバに状態要素"a" と状態要素"h" が記録されている。また、管理ドメインD1の最大番号が状態要素"i" の番号「8 」に更新されている。また、グループ"D1::G1"の関連ドメインに管理ドメインD2が記録されている。
図19(b)を参照すると、状態要素"b,f,g" が探索された結果として、グループ"D1::G1"のメンバに状態要素"b" 、状態要素"f" 、および状態要素"g" が記録されている。また、管理ドメインD2の最大番号が状態要素"y" の番号「10」に更新されている。また、グループ"D1::G1"の関連ドメインに管理ドメインD1が記録されている。
図20は、強連結成分分解の処理において協調部間で送受信される通信内容の一例を示す説明図である。図20(a)に示す要求メッセージには、グループidが含まれている。また、図20(b)に示す返答メッセージには、さらにグループに参加する新規メンバが存在する旨が記されている。
強連結成分分解の処理が実行された結果、図18に示す状態要素群は、図21に示す複数のグループに分割される。図21は、ステップS1400 のグループ分割処理により生成されるグループの一例を示す説明図である。図21に示す破線の楕円が、グループ分割処理により生成されるグループを表す。
次に、ステップS1500 のプランニングを説明する。図22は、第1の実施形態の計画部102によるプランニングの全体動作を示すフローチャートである。
計画部102は、全てのグループに対して手順を探索するために、手順が未探索のグループが残っているか否かを全ての管理ドメインに渡って確認する(ステップS1510 )。未探索のグループが残っていない場合(ステップS1510 におけるYes )、計画部102は、プランニングを終了する。
未探索のグループが残っている場合(ステップS1510 におけるNo)、計画部102は、未探索のグループを1つ取り出す。次いで、計画部102は、取り出されたグループを起点とした深さ優先探索処理を実行することによって、手順探索可能なグループを探索しつつ、順次手順探索処理を実行する(ステップS1520 )。深さ優先探索処理を実行した後、計画部102は、再度ステップS1510 の処理を行う。
手順探索可能なグループは、他のグループ内の手順探索済みでない状態要素と自グループ内の状態要素との間に関係性が無いようなグループである。または、手順探索可能なグループは、他のグループ内の手順探索済みでない状態要素との間に自グループ内の状態要素を指定する関係性が無いようなグループである。
図21に示す例であれば、グループ"D1::G2"内の状態要素"i" は、グループ"D1::G1"内の状態要素"a" との間に自身を指定する関係性を有する。すなわち、グループ"D1::G2"は、手順探索可能なグループではない。
また、グループ"D1::G1"内の全ての状態要素は、他のグループ内の状態要素との間に上記のような関係性を有しない。すなわち、グループ"D1::G1"は、手順探索可能なグループである。なお、グループ"D1::G1"に対する手順探索処理が実行された後であれば、グループ"D1::G2"は手順探索可能なグループになる。
図21に示す例において、手順が未探索のグループとして最初にグループ"D1::G2"が選択された場合、計画部102は、グループ"D1::G2"を起点として、グループがノード、グループ間の関係性を表す矢印の逆向きの矢印がエッジとみなされた第1の深さ優先探索処理を実行する。
次いで、計画部102が終端から順に手順探索処理を実行することによって、グループ"D1::G1"、グループ"D1::G2"の順に手順探索処理が実行される。以上で、ステップS1520 の処理である1回目の第1の深さ優先探索処理が終了する。以降、計画部102が同様の処理を繰り返し実行することによって、全てのグループに対して手順探索処理が実行される。
以下、プランニングを構成する副処理を説明する。最初に、ステップS1520 の手順生成処理を説明する。図23は、第1の実施形態の計画部102による手順生成処理の動作を示すフローチャートである。図23に示す処理は、1つのグループに関する手順計画処理である。
計画部102は、処理対象のグループが複数の管理ドメインを跨ぐか否かを確認する(ステップS1521 )。複数の管理ドメインを跨いでいない場合(ステップS1521 におけるNo)、計画部102は、グループが存在する管理ドメイン内で手順探索処理を実行し、部分的な手順を生成する(ステップS1522 )。部分的な手順を生成した後、計画部102は、ステップS1523 の処理を行う。
複数の管理ドメインを跨ぐ場合(ステップS1521 におけるYes )、計画部102は、部分的な手順の生成処理を結合部120に依頼する(ステップS1530 )。ステップS1530 の処理では、変更手順の生成処理の起点である管理ドメイン内の計画システムが、結合部120に対して処理対象のグループに対する手順探索処理を依頼する。結合部120は、関連する各管理ドメインにおける部分的な手順を生成する。
図24は、協調部と結合部との間で送受信される通信内容の一例を示す説明図である。図24(a)は、協調部から結合部へ送信される変更手順の生成処理の要求メッセージを示す。
図24(a)に示す要求内容には、グループid以外に、依頼元の管理ドメインにおけるグループのメンバである状態要素や関連ドメインが含まれている。また、状態要素の情報として、手順探索に要する一連の情報である、取り得る状態、実行可能な状態遷移、現在状態、および目的状態までが含まれている。
図24(b)は、結合部から協調部へ送信される変更手順の生成処理の要求に対する返答メッセージを示す。図24(b)に示す返答内容には、処理結果に相当する部分的な手順を示す情報が含まれている。結合部120から部分的な手順を示す情報を受信した後、計画部102は、ステップS1523 の処理を行う。
次いで、計画部102は、得られた部分的な手順を、他のグループに対する手順生成処理で得られた部分的な手順と結合する(ステップS1523 )。部分的な手順同士を結合した後、計画部102は、手順生成処理を終了する。
なお、グループが管理ドメインを跨ぐ場合には、グループに属するメンバが2つ以上の管理ドメインに存在する場合だけでなく、他の管理ドメイン内の状態要素との間に関係性を有する場合も含まれる。その理由は、関係性を有する他の管理ドメイン内の状態要素に対してもグループと共に手順探索処理が実行されることが求められるためである。
図21に示す例であれば、グループ"D1::G1"、グループ"D2::G1"、およびグループ"D3::G1"が複数の管理ドメインを跨ぐグループであると判断される。
なお、ステップS1522 の手順探索処理は、例えば特許文献2に記載されている方法に従って実行される。また、ステップS1523 の部分的な手順の結合処理は、例えば特許文献3に記載されている方法に従って実行される。
以下、手順生成処理を構成するステップS1530 の手順探索処理を説明する。図25は、第1の実施形態の結合部120による手順探索処理の動作を示すフローチャートである。
計画システム100から部分的な手順の生成処理の依頼を受け付けると、結合部120は、関連ドメインに記載されている全ての管理ドメインから処理対象のグループに関連する状態要素を収集する(ステップS1531 )。
次いで、結合部120は、収集された状態要素を結合することによって、手順探索問題を生成する(ステップS1532 )。次いで、結合部120は、生成された手順探索問題に対して手順探索処理を実行し、システム構成の変更手順を生成する(ステップS1533 )。
システム構成の変更手順を生成した後、結合部120は、生成された変更手順を各関連ドメインから収集された情報に基づいて分割する(ステップS1534 )。次いで、結合部120は、分割で得られた各部分的な手順を、各管理ドメイン内の計画システムに通知する(ステップS1535 )。各部分的な手順をそれぞれの計画システムに通知した後、結合部120は、手順探索処理を終了する。
図26は、協調部と結合部との間で送受信される通信内容の他の一例を示す説明図である。図26(a)は、結合部から協調部へ送信される情報の要求メッセージを示す。図26(a)に示す要求内容には、結合部120が手順探索処理に要するグループidが含まれている。
図26(b)は、協調部から結合部へ送信される返答メッセージを示す。図26(b)に示す返答内容には、送信されたグループidが示すグループのメンバである状態要素の具体的な情報が含まれている。
図27は、結合部120内に記録される情報の一例を示す説明図である。例えば、結合部120にグループ"D1::G1"の部分的な手順の生成処理が依頼された場合、結合部120は、全ての関連ドメインから手順探索処理に要する情報を収集する。
情報を収集した後、結合部120は、図27に示すような管理ドメインごとの状態要素の情報を生成する。なお簡略化のため、図27において状態要素"a" 以外の状態要素の内容を示す情報は省略されている。
図27に示す状態要素"a" の事前状態制約内の"D2::b.s1"のような管理ドメインの情報が含まれる関係性から管理ドメインの情報が除去されると、一般的な手順探索問題と同様の形式の手順探索問題が得られる。結合部120が図27に示す情報から生成された手順探索問題に対して手順探索処理を実行した結果、図28に示すシステム構成の変更手順が生成された場合を考える。
図28は、結合部120が生成するシステム構成の変更手順の一例を示す説明図である。図28は、結合部120が生成した分割される前のシステム構成の変更手順を示す。図28に示す矩形は、手順を表す。また、矩形内の文字が、手順で実行される作業を表す。
図27に示す情報を参照することによって、結合部120は、状態要素"a" と状態要素"h" が管理ドメインD1に由来する状態要素であることが分かる。また、結合部120は、状態要素"b" 、状態要素"f" 、および状態要素"g" が管理ドメインD2に由来する状態要素であることが分かる。
よって、結合部120は、得られたシステム構成の変更手順を、管理ドメインD1に由来する手順"a(s1->s2)" および手順"h(s1->s2)" と、管理ドメインD2に由来する手順"g(s1->s2)" 、手順"f(s1->s2)" 、および手順"a(s1->s2)" に分割できる。
また、手順"a(s1->s2)" が実行された後に手順"b(s1->s2)" が実行されるような、生成された変更手順が複数の管理ドメインに渡る順序性を有する場合、結合部120は、適当な一意の識別情報として"D1::G1.X"等を生成する。
次いで、結合部120は、先に実行される手順"a(s1->s2)" の後に命令"call D1::G1.X" を配置する。また、結合部120は、後に実行される手順"b(s1->s2)" の前に命令"wait D1::G1.X" を配置する。
各命令が配置された変更手順を図29に示す。図29は、結合部120が生成するシステム構成の変更手順の他の一例を示す説明図である。図29は、結合部120が生成した分割された後のシステム構成の変更手順を示す。
図29(a)は、管理ドメインD1内の計画システムの実行対象である部分的な手順を示す。また、図29(b)は、管理ドメインD2内の計画システムの実行対象である部分的な手順を示す。以上のように、結合部120が手順探索処理を実行することによって、各計画システムの実行対象である部分的な手順が完成する。
以上の全ての処理が終了した後、例えば図7(d)に示すような、管理ドメインごとに生成され、かつ管理ドメイン間で関連している一連のシステム構成の変更手順が形成される。各管理ドメイン内の計画システムは、管理ドメインごとに生成された部分的な手順を確認することによって、自身が管理するシステムにシステム構成変更が及ぼす影響を事前に確認できる。各管理ドメイン内の計画システムがそれぞれの制御装置400等を用いて一斉にシステム構成の変更手順に従って変更処理を実行することによって、一連のシステム構成変更が協調的に実行される。
なお、本実施形態の計画システム100の協調部101は、以下に示す処理を行ってもよい。
本実施形態に示す方法には、所定の管理ドメインで定義された状態要素の余分な情報まで他の管理ドメインや結合部120に通知されてしまうという問題がある。状態要素の情報は、基本的に状態要素を管理する管理ドメイン内の計画システムのみが把握していればよい。
例えば複数の管理ドメインを跨ぐ関係性が指定される際等には、状態要素を示すidや状態の情報に関して、別名が用いられてもよい。また、結合部120に手順計画を依頼する際にも、協調部101は、状態要素を示すidや取り得る状態の情報を別名に変換した上で依頼し、受け取った変更手順における別名を元の情報に読み替えればよい。
本実施形態の変形例として、協調部101は、状態要素の情報を、情報が匿名化された情報と対応付けて管理する情報テーブルを有する。他の管理ドメインや結合部120へ情報を送信する際、協調部101は、匿名化された情報を送信する。また、他の管理ドメインや結合部120から情報を受信した際、協調部101は、匿名化された情報を元の情報に戻す処理をさらに行う。
図30は、管理ドメインごとの匿名情報の一例を示す説明図である。図30(a)は、管理ドメインD1における匿名情報を示す。図30(b)は、管理ドメインD2における匿名情報を示す。本変形例の協調部101は、図30に示すような状態要素や後述するフィールドに関する匿名情報を記録する。協調部101は、記録された匿名情報を用いて、匿名化処理や、匿名化された情報を元の情報に戻す処理を実行する。
図30に示す" 再現情報" は、匿名化された情報から元の情報を得るために利用される対応情報である。また、" 匿名化情報" は、一貫性を持って元の情報を匿名化するために利用される対応情報である。
協調部101は、新たに匿名化の対象になる状態要素やフィールドが生じた場合、匿名を生成し" 匿名化情報" に追記する。協調部101は、ランダムな文字列等を適宜生成し匿名として用いればよい。
本変形例によれば、複数の管理ドメインそれぞれで管理されるシステムが関連する場合であっても、管理ドメイン間でシステム構成定義の内容が秘匿されたままシステム構成の変更手順が生成される。
[効果の説明]
本実施形態の計画システム100は、複数の管理ドメインそれぞれで管理されるシステムが関連し、全体を把握している構成要素が存在しない場合であっても、システム構成の変更手順を生成できる。本実施形態では、複数の管理ドメインに影響を及ぼす一連のシステム構成変更が各管理ドメイン内の計画システムの協調動作により実現されるようなシステム構成の変更手順が、各管理ドメインで生成される部分的な手順の集合として生成される。
本実施形態の計画システム100は、協調部101と、計画部102とを含む。システム構成定義は、構成要素の集合と構成要素間の関係性とで表現される。また、関係性には、他の計画システム群が管理するシステム構成定義内の構成要素との関係性が含まれる。
計画部102は、協調部101を介して他の計画システム群と通信し、協調して手順計画を実行する。協調して手順計画が実行されることによって、複数の管理ドメイン内の計画システムが協調して実行可能なシステム構成の変更手順の一部である、該当する管理ドメインに関するシステム構成の変更手順が生成される。
本実施形態の結合部120が使用されると、複数の管理ドメインそれぞれで管理されるシステム間に関係性が存在する場合であっても計画システムが利用される。各計画システムは、各管理ドメイン内で及ぶ影響を確認した上で、システム構成を変更できる。また、手順探索処理の実行のために状態要素を一箇所に集めることが避けられない場合であっても、本実施形態の調整部103は、集められる対象の状態要素の数を抑えることができる。
本実施形態の方法が使用されると、複数の管理ドメインそれぞれで管理されるシステムが関連する場合であっても計画システムが利用される。利用者は、各管理ドメイン内で及ぶ影響を確認した上で、システム構成を変更できる。
(第2の実施の形態)
[構成の説明]
次に、本発明の第2の実施形態を、図面を参照して説明する。図31は、本発明による計画システムの第2の実施形態の構成例を示すブロック図である。
図31に示すように、本実施形態の計画システム100aは、協調部101と、計画部102と、調整部103と、コンパイル部104とを含む。すなわち、本実施形態の計画システム100aの構成は、コンパイル部104が含まれる点以外は第1の実施形態の計画システム100の構成と同様である。
コンパイル部104は、利用者がシステム構成の変更要求として入力した高級なシステム構成定義を、計画部102が処理できる低級なシステム構成定義に変換する機能を有する。なお、コンパイル部104は、計画部102と通信ネットワーク等を介して通信可能に接続されている。
第1の実施形態に示す状態要素群が用いられるシステム構成定義の表現方法には、大規模なシステム構成の定義の手動での表現が困難であるという問題がある。
特許文献3には、上記の問題を解決する、複数の状態要素群で構成された部分構成定義が再利用可能にまとめて抽象化されたコンポネントが用いられた高級なシステム構成定義を利用する方法が記載されている。
図32は、一般的な高級なシステム構成定義の一例を示す説明図である。図32に示す角丸四角形はコンポネントを表し、実線の矩形は状態要素を表す。角丸四角形内の文字がコンポネントの名称であり、実線の矩形内の文字が状態要素の名称である。なお簡略化のため、図32には状態要素内の状態や状態遷移が示されていない。
図32は、"component1"と"component2"の2つのコンポネントを示す。また、コンポネント"component1"には、"vm1" と"vm2" の2つの状態要素が含まれている。また、コンポネント"component2"には、状態要素"functionX2"が含まれている。
また、図32に示す実線の山形および実線の矢羽形は、それぞれポートを表す。実線の山形の上の文字および実線の矢羽形の左上の文字がポートの名称である。一般的な高級なシステム構成定義では、コンポネントは、他のコンポネントとポートを介して結合する。ポート間の接続は、ワイヤとも呼ばれる。
ポートには、機能を要求するリファレンスポートと、機能を提供するサービスポートがある。リファレンスポートは、要求する機能の情報を有する。また、サービスポートは、提供する機能の情報を有する。ワイヤは、常に同じ機能の情報を有するリファレンスポートとサービスポートとを接続するように定義される。
図32に示すように、リファレンスポートは実線の山形で、サービスポートは実線の矢羽形で、ワイヤはポート間の二重線でそれぞれ表現される。図32に示すリファレンスポート"reference1"、およびサービスポート"service2"は、共に"API1"という機能の情報を有する。
また、図32に示す破線の矩形、および破線の山形は、それぞれフィールドを表す。破線の矩形の左上の文字および破線の山形の上の文字がフィールドの名称である。フィールドは、状態要素を格納するコンポネントの構成要素である。なお、山形のフィールドは、後述するようにポート内でのみ定義される特殊なフィールドである。
一般的な高級なシステム構成定義では、状態要素間の関係性は、フィールドを介して抽象的に定義される。例えば、コンポネント"component1"のフィールド"vm12"とフィールド"agent1"との間に関係性が定義されている。すなわち、フィールド"vm12"に格納された状態要素"vm2" と、フィールド"agent1"に格納された状態要素"agentD1" との間に、フィールド間に定義された関係性と同様の関係性が存在すると解釈される。
また、図32に示す状態要素"agentD1" は、制御モジュールを表す特殊な状態要素である。図32に示すように、制御モジュールは、二重線の矩形で表現される。また、状態要素"A" が制御モジュール"B" で制御されるという関係性は、両端に黒丸を有する実線で表現される。
すなわち、図32に示すフィールド"vm12"とフィールド"agent1"との間に存在する実線は、フィールド"vm12"内の状態要素の配備や削除等の操作がフィールド"agent1"内の制御モジュール"agentD1" により実行されることを表す。
また、図32に示す状態要素"redundant" は、複数の状態要素に渡る一般的な制約条件を表す特殊な状態要素である。条件の内容は、それぞれの制約条件ごとに定義される。図32に示すように、制約条件は、三重線の矩形で表現される。また、状態要素が制約条件に従うことは、事前状態制約と同様に、制約条件から状態要素へ伸びる破線の矢印で表現される。
図32に示す制約条件"redundant" は、関連する状態要素"vm1" と状態要素"vm2" のうち、少なくとも1つは起動状態になるように、計画部102による手順計画の動作や制御装置400の動作等を制約する。
複数のコンポネントが結合されると、各コンポネントが含む状態要素が一括で関係付けられる。例えば、図32に示すコンポネント"component1"内の状態要素"vm1" は、コンポネント"component2"内の制御モジュール"agentD2" と関係付けられる。
その理由は、状態要素"vm1" は、ポートを介してコンポネント"component2"内のフィールド"vm21"にまで接続されている。すなわち、フィールド"vm21"とフィールド"agent2"との間に定義された関係性を、状態要素"vm1" も有するからである。
同様に、コンポネント"component2"内の状態要素"functionX2"は、コンポネント"component1"内の状態要素"vm1" 、および状態要素"vm2" とそれぞれ関係付けられる。
上記のような定義が表現されるために、一般的な高級なシステム構成定義では、ポート内にフィールドが定義される。また、コンポネント内のフィールドに格納されている状態要素が、コンポネントが有するポート内のフィールドまで接続される。
ポート内のフィールドには、右向きの山形で表現されるアクセプトフィールドと、左向きの山形で表現されるプロバイドフィールドとがある。状態要素は、アクセプトフィールドを介してリファレンスポートからサービスポートに接続される。また、状態要素は、プロバイドフィールドを介してサービスポートからリファレンスポートに接続される。
図32に示す例では、コンポネント"component1"が有するポート"reference1"内にフィールド"vm"が定義されている。また、フィールド"vm"は、フィールド"vm11"を参照している。すなわち、フィールド"vm11"に格納されている状態要素"vm1" が、ポート"reference1"内のフィールド"vm"まで接続される。
図32に示すように、フィールドによる状態要素の参照は、フィールド内の黒丸が始点である矢印で表現される。なお、状態要素の接続の方向は、参照を表現する矢印の向きと逆の方向である。
上記の通り、結合される2つのポートは、同じ機能の情報を有する。また、同じ機能の情報を有するポート同士は、対応するフィールドを含む。
図32に示す状態要素"vm1" は、ポート"reference1"内のフィールド"vm"からさらにポート"service2"内のフィールド"vm"まで接続される。最終的に、状態要素"vm1" は、フィールド"vm"からコンポネント"component2"内のフィールド"vm21"まで接続される。
上記のような表記が用いられるため、高級なシステム構成定義が使用されると、同じ機能を有するポートを含むコンポネント同士であれば、異なるコンポネントが組み合わせられて表現される。すなわち、多様なシステム構成が定義される点が、上記の高級なシステム構成定義が使用される場合の利点である。フィールドを介して関係性が指定される点や、状態要素が複数のフィールドに接続される点も、同様の利点が得られるための特徴である。
一般的な高級なシステム構成定義の低級なシステム構成定義へのコンパイルは、コンポネントやコンポネント間の結合関係に関する定義を基にコンポネント内の状態要素同士を関係付けることによって得られる状態要素群を生成する処理である。
図32に示すシステム構成定義がコンパイルされた結果を図33に示す。図33は、高級なシステム構成定義がコンパイルされた低級なシステム構成定義の一例を示す説明図である。
本実施形態の高級なシステム構成定義では、異なる管理ドメインに存在する複数のコンポネントが結合されている。本実施形態のコンパイル部104は、異なる管理ドメインに存在する複数のコンポネントが結合されている高級なシステム構成定義を基に、複数の管理ドメインに跨る低級なシステム構成定義を生成する。
上記の処理が実現されるために、本実施形態のシステム構成定義では、サービスポートが外部に公開されるように指定されたり、外部に公開された他の管理ドメイン内のポートとの結合関係が定義されたりする。
図34は、第2の実施形態の高級なシステム構成定義の一例を示す説明図である。図34は、管理ドメインD2におけるシステム構成定義を示す。図34に示すメタ情報には、コンポネント"component2"が有するサービスポート"service2"が提供するサービスが、" 公開サービス" であることが指定されている。なお、メタ情報は、システム構成定義内の情報をさらに定義する情報である。
図35は、第2の実施形態の高級なシステム構成定義の他の一例を示す説明図である。図35は、管理ドメインD1におけるシステム構成定義を示す。図35に示すポート"D2::component2.service2" は、リファレンスポート"reference1"が管理ドメインD2内のコンポネント"component2"が有するサービスポート"service2"を参照していることを示す。すなわち、リファレンスポート"reference1"がサービスポート"D2::component2.service2" に接続されることによって、複数の管理ドメインを跨るワイヤが定義される。
なお、図35に示す"component2.service2" のような"." で名詞を繋ぐ表現は、"component2"の中の"service2"という包含関係を表す。他の記載も同様の意味を有する。
図34に示す高級なシステム構成定義が単独でコンパイルされると、管理ドメインD2内に図36に示すような低級なシステム構成定義が生成される。図36は、第2の実施形態の高級なシステム構成定義がコンパイルされた低級なシステム構成定義の一例を示す説明図である。
図35に示す高級なシステム構成定義を定義に関連する管理ドメインD1内の計画システムと管理ドメインD2内の計画システムが協調した上でコンパイルすると、各管理ドメイン内に図37に示すような低級なシステム構成定義が生成される。図37は、第2の実施形態の高級なシステム構成定義がコンパイルされた低級なシステム構成定義の他の一例を示す説明図である。
例えば、2つのシステム構成定義を比較し、2つの定義の差分に基づいて各状態要素の現在状態と目的状態を決定する方法がある。図36に示すシステム構成定義と図37に示すシステム構成定義との差分から得られるシステム構成の変更要求定義を図38に示す。
図38は、第2の実施形態のシステム構成の低級な変更要求定義の一例を示す説明図である。図38に示す状態"t" は、状態要素が存在する状態を表す。また、状態"f" は、状態要素が存在しない状態を表す。
例えば、状態要素"functionX2"は、図36に示すシステム構成定義と図37に示すシステム構成定義の両方に存在するため、現在状態および目的状態がいずれも状態"t" になる。また、状態要素"vm1" と状態要素"vm2" は、図37に示すシステム構成定義にのみ存在するため、現在状態が状態"f" 、目的状態が状態"t" にそれぞれなる。
図38に示すシステム構成の変更要求定義は、制約条件"redundant" 以外に関して、第1の実施形態に示す方法で計画部102により処理される。制約条件は、後述するように処理される。また、本実施形態の計画部102は、本実施形態の制御モジュールを単純に無視してもよい。
本実施形態では、制約条件や制御モジュールではない一般的な状態要素は、コンパイルの過程で1つの制御モジュールと関連付けられたフィールドに接続される。コンパイルされた後にフィールドに接続された状態要素は、フィールドが管理される管理ドメインにおいて管理される。本実施形態では、状態要素が接続されたフィールドを状態要素に関する管理フィールドと呼ぶ。
また、関係性は、状態要素の接続経路上のいずれのフィールドでも定義される。しかし、全ての関係性は、コンパイルされた後に各状態要素に関する管理フィールドにおいて定義される識別情報に基づいた関係性に変換されることが求められる。
[動作の説明]
以下、本実施形態の計画システム100aの動作を図39〜図40を参照して説明する。図39は、第2の実施形態の計画システム100aによる高級なシステム構成定義のコンパイル処理の具体例を示す説明図である。
図39に示す矩形はフィールドを表し、実線の矢印は状態要素の接続経路を表す。また、二重線の矩形は、システム構成定義で状態要素を格納するように定義されたフィールドを表す。また、黒色の矩形は、制御モジュールと関連付けられたフィールドを表す。
また、図39に示すフィールド内の文字は、フィールドのidと、接続された状態要素のidを表す。例えば、フィールド内の「a:A 」は、フィールドのidが「a 」であり、接続された状態要素のidが「A 」であることを表す。
また、図39(a)に示すフィールド"c" からフィールド"y" へ伸びるように定義された関係性は、図39(d)に示す管理フィールドにおいて定義された識別情報であるフィールド"d:A" からフィールド"z:X" へ伸びる関係性に変換されている。
上記の処理は、図35に示すフィールド"D1::component1.vm12" からフィールド"D1::component1.reference1.functionX" へ伸びるように定義された関係性が、図37に示す状態要素"D1::vm2" から状態要素"D2::functionX2"へ伸びる関係性に変換される処理に相当する。
各状態要素に関して、最初に接続経路上のフィールドで構成されたグラフと管理フィールドが識別される。図39(a)に示す例では、フィールド"a" に状態要素"A" が含まれる場合、フィールド"a" を起点とした深さ優先探索処理が行われることによって状態要素"A" の管理フィールドがフィールド"d" であると識別される。
識別された結果、フィールド"a" 内に状態要素"A" の管理フィールドがフィールド"d" であることが記録される。図39において、記録された情報はフィールドの上の吹き出しの中に示されている。
また、フィールド"a" からフィールド"d" に至る経路に存在するフィールド"b" とフィールド"c" は、状態要素"A" の主要な接続経路上のフィールドとして記録される。図39に示す実線の矩形は、主要な接続経路上のフィールドを表し、点線の矩形は他のフィールドを表す。コンパイル部104は、同様の操作をフィールド"x" 内の状態要素"X" に対しても実行する。
次いで、コンパイル部104は、決定された管理フィールドの情報を接続経路上の各フィールドに通知する。図39(b)は、管理フィールドの情報が通知された時点のシステム構成定義の状態を示す。
次いで、コンパイル部104は、管理フィールドを起点として接続経路のグラフに対して深さ優先探索処理を実行し、関係性を収集する。深さ優先探索の起点を管理フィールドにするために、コンパイル部104は、上記の「主要な接続経路」における探索方向の逆向きに探索処理を行う。
その理由は、例えば、図39(a)に示すフィールド"d" を起点として状態要素"A" の接続経路を探索する場合、フィールド"c,b,a" の探索には該当部分のエッジの向きを反転させることが求められるためである。
図39(c)に示す例では、フィールド"d" を起点とした状態要素"A" の探索において、フィールド"c" でフィールド"y" との関係性の定義が発見される。続いて、フィールド"y" に記録された状態要素"X" の管理フィールドであるフィールド"z" が参照されることによって、関係性が最終的にフィールド"z:X" と結ばれればよいことがわかる。
図39(d)は、生成されたコンパイル結果を示す。第2の実施形態のコンパイル部104は、上記のような動作を複数の管理ドメイン内の計画システムと協調しながら実行する。
図40は、第2の実施形態の計画システム100aによる高級なシステム構成定義のコンパイル処理の動作を示すフローチャートである。
本実施形態の計画部102は、入出力装置200を介して利用者からシステム構成の変更要求を受け付ける(ステップS2100 )。次いで、計画部102は、受け付けられたシステム構成の変更要求が一意に特定される変更要求idを生成する。
次いで、計画部102は、システム構成の変更要求に関する情報を記録するための記憶領域を記憶装置300に生成する。記憶領域を生成した後、計画部102は、システム構成の変更要求をコンパイル部104に転送する。
コンパイル部104は、転送されたシステム構成の変更要求内の高級なシステム構成定義から、自身が存在する管理ドメイン以外の関連する管理ドメイン内のポートの情報を抽出する。次いで、コンパイル部104は、協調部101を介して関連する管理ドメイン内の計画システムにコンパイル処理の開始を要求する(ステップS2200 )。
コンパイル処理の開始の要求を受け付けた管理ドメイン内の計画システムは、コンパイル処理に関する記憶領域を生成する。図41は、コンパイル処理の開始の要求時および返答時に送受信される通信内容の一例を示す説明図である。図41(a)は、コンパイル処理の開始の要求メッセージを示す。また、図41(b)は、コンパイル処理の開始の要求に対する返答メッセージを示す。
次いで、関連する全ての管理ドメイン内のコンパイル部104は、状態要素が定義されたフィールドを起点として、フィールドがノードであり、参照を表す矢印の逆向きの矢印がエッジである深さ優先探索処理を実行する。コンパイル部104は、各状態要素の接続経路で構成されたグラフを形成すると共に、管理フィールドを識別する(ステップS2300)。
例えば、図35に示す状態要素"vm1" に関する深さ優先探索処理では、最初に状態要素"vm1" が格納されたフィールド"component1.vm11" が、探索が開始されるフィールドになる。フィールド"component1.vm11" は別のフィールド"component1.reference1.vm"から参照されているため、フィールド"component1.reference1.vm"は、接続経路上の次のノードの1つになる。
次いで、ポート"reference1"が他の管理ドメイン内のポート"D2::component2.service2" に接続されているため、探索を依頼された管理ドメインD2内の計画システムが探索を継続して実行する。
図42は、管理フィールドの探索の要求時および返答時に送受信される通信内容の一例を示す説明図である。図42(a)は、管理フィールドの探索の要求メッセージを示す。図42(a)に示すように、探索を依頼する側の管理ドメイン内の計画システムは、探索対象の状態要素を示すidと探索先のフィールドを要求メッセージに含める。
また、図42(b)は、管理フィールドの探索の要求に対する返答メッセージを示す。図42(b)に示すように、探索が依頼される側の管理ドメイン内の計画システムは、状態要素の管理フィールドが発見されれば、発見された管理フィールドを返答する。
また、図43は、管理フィールドの探索中の管理ドメインごとの記録情報の一例を示す説明図である。図44は、管理フィールドの探索中の管理ドメインごとの記録情報の他の一例を示す説明図である。図43および図44に示すように、各状態要素の深さ優先探索処理の開始時に、計画システムは、最初に" 状態要素" の項目に探索対象の状態要素を示す情報と開始フィールドを記録する。
各フィールドが探索された際、計画システムは、記録された状態要素の中の" 接続経路" の項目に探索されたフィールドを示すidを追記する。また、計画システムは、フィールド間の参照関係に基づいて、接続経路上の次のフィールドや前のフィールドを記録する。
探索されたフィールドが管理フィールドであれば、計画システムは、探索されたフィールドを状態要素の管理フィールドとして" 管理フィールド" の項目に記録する。フィールドの探索を終えて探索元の計画システムに処理を戻す際、計画システムは、管理フィールドが発見されていれば状態要素の" 主要な接続経路" に"yes" を記録する。
また、管理フィールドが発見されていなければ、計画システムは、状態要素の" 主要な接続経路" に"no"を記録する。" 主要な接続経路" に情報を記録した上で、計画システムは、探索元の計画システムに管理フィールドの情報を返す。
他の管理ドメイン内の計画システムから探索を依頼された場合、計画システムは、最初に" 状態要素" の項目に依頼された探索対象の状態要素を示す情報を記録する。記録した後、計画システムは、接続経路上のフィールドを示す情報を同様に追記する。
図43は、探索対象の状態要素が管理ドメインD1内の状態要素"vm1"や状態要素"D2::functionX2"である記録情報を示す。また、図44は、探索対象の状態要素が状態要素"D1::vm1" や管理ドメインD2内の状態要素"functionX2"である記録情報を示す。
なお、全く接続しない状態要素は、図43に示す管理ドメインD1内の状態要素"vm2" のように、開始フィールドと管理フィールドがフィールド"component1.vm12" で同一である。また、接続経路にも、フィールド"component1.vm12" のみが含まれる。図43において、状態要素"vm2" 以外の接続しない状態要素の具体的な情報は省略されている。
次いで、関連する全ての管理ドメイン内のコンパイル部104は、状態要素が定義されたフィールドを起点として、フィールドがノードであり、参照を表す矢印の逆向きの矢印がエッジである深さ優先探索処理を実行する。コンパイル部104は、各フィールドに各状態要素の管理フィールドを記録する(ステップS2400 )。
図45は、管理フィールドの情報が通知された後の管理ドメインごとの記録情報の一例を示す説明図である。図45(a)は、管理ドメインD1における記録情報を示す。図45(b)は、管理ドメインD2における記録情報を示す。
次いで、関連する全ての管理ドメイン内のコンパイル部104は、管理フィールドを起点とした深さ優先探索処理を実行し、関係性を示す情報を収集する(ステップS2500 )。例えば、図44に示す" 管理フィールド" には、状態要素"D1::vm1" の管理フィールドが"component2.vm21" であると記録されている。
よって、コンパイル部104は、図44に示す" 状態要素" の項目の"D1::vm1" における"component2.vm21" から探索を開始する。基本的に探索対象は" 次のフィールド" に記載されたフィールドである。なお、" 次のフィールド" に記載されたフィールドが主要な接続経路上に存在すれば、すなわち" 主要な接続経路" の項目が"yes" であれば、" 前のフィールド" に記載されたフィールドも探索の対象になる。
探索中に関係性が発見された場合、コンパイル部104は、管理フィールドを参照して、発見された関係性に管理フィールドが加えられた情報を探索元の計画システムに返す。図35に示す例では、フィールド"component1.vm11" は、フィールド"component1.reference1.functionX" やフィールド"component1.redundant"との間に関係性が定義されている。
フィールド"component1.vm11" の探索時に上記の関係性の定義が発見されると、コンパイル部104は、図45(a)に示す情報を参照する。参照することによって、コンパイル部104は、フィールド"component1.reference1.functionX" には状態要素"D2::functionX2"が含まれており、状態要素"D2::functionX2"の管理フィールドが"D2::component2.functionX"であることを把握する。
また、コンパイル部104は、フィールド"component1.redundant"には状態要素"redundant" が含まれており、状態要素"redundant" の管理フィールドが"component1.redundant"であることを把握する。コンパイル部104は、把握された情報をまとめて探索元の計画システムに返す。
図46は、関係性の収集の要求時および返答時に送受信される通信内容の一例を示す説明図である。図46(a)は、関係性の収集の要求メッセージを示す。また、図46(b)は、関係性の収集の要求に対する返答メッセージを示す。図46に示すように、状態要素を示すidと管理フィールドを示すidとが" @" で繋がれている。" @" で繋がれた情報は、まとめられた情報を表現している。
各管理ドメイン内のコンパイル部104は、管理フィールドごとに全ての状態要素に関する関係性の情報を取りまとめる。図47は、管理ドメインごとに関係性がまとめられた記録情報の一例を示す説明図である。図47(a)は、管理ドメインD1における記録情報を示す。図47(b)は、管理ドメインD2における記録情報を示す。
次いで、コンパイル部104は、全ての状態要素に関して、管理フィールドを有する各管理ドメインに状態要素の取り得る状態や実行可能な状態遷移等の手順計画に要する情報を通知する。各管理ドメイン内の計画システムは、通知された情報を状態要素に追加し、低級なシステム構成定義を完成させる。
コンパイル部104は、完成された低級なシステム構成定義を計画部102に入力する(ステップS2600 )。入力した後、計画システム100aは、高級なシステム構成定義のコンパイル処理を終了する。
なお、本実施形態で例示された"redundant" のような制約条件に対する調整部103による影響範囲抽出処理の方法やグループ分割処理の方法は、事前状態制約に対する各方法と異なる。以下、制約条件に関して異なる点を補足する。
影響範囲抽出処理の方法が異なる理由を説明するために、例えば制約条件の内容が「関連する状態要素のうち少なくとも1つの状態は状態"t" であること」という場合を考える。1つの状態要素の状態が状態"f" になるのであれば、他の状態要素のうちの少なくとも1つの状態要素の状態を状態"t" に変更することが求められる。よって、制約条件に対する影響範囲抽出処理の方法は、事前状態制約に対する方法と異なる。
上記のように、影響範囲の判定方法は、制約条件の内容に依存する。しかし、少なくとも関連する全ての状態要素が影響範囲に加えられれば、手順計画は正しく実行される。
よって、影響範囲を探索する際、調整部103は、所定の状態要素が変更される場合には変更される状態要素を参照する制約条件に影響が及ぶ可能性があると判断して探索すればよい。反対に、所定の制約条件が変更される場合、調整部103は、変更される制約条件が参照する全ての状態要素に影響が及ぶ可能性があると判断して探索すればよい。
また、同様にグループ分割処理では、所定の制約条件と参照対象の全ての状態要素が同じグループに所属することが求められる。制約条件と参照対象の全ての状態要素を同じグループに所属させるために、調整部103は、強連結成分分解において単に所定の制約条件と状態要素群との間にそれぞれに向いた2つのエッジが存在すると解釈して探索すればよい。
なお、本実施形態に示す制約条件等が用いられて各管理ドメインに許容可能なシステム構成の変更手順の条件が事前に設定されれば、各管理ドメイン内の計画システムは、設定された条件に違反しないことを前提にシステム構成変更の実行を自動的に許可してもよい。
また、計画システムは、実行を許可した旨をシステム構成変更が受け付けられた管理ドメインに通知してもよい。すなわち、システム構成変更の受け付けから複数の管理ドメインを跨る変更までの処理全体が自動的に実行される。
なお、本実施形態の協調部101も、第1の実施形態の変形例と同様に、情報の匿名化処理を行ってもよい。ただし、図34および図35に示す外部に公開されるポートや、外部に公開されるポートに接続される状態要素の情報は、そもそも他の管理ドメインに通知されることが意図された情報であるため、匿名化処理の対象外である。
本実施形態において匿名化および再現の対象になる通信には、ステップS2300 での管理フィールドを発見する際に行われる通信、ステップS2400 での接続経路上のフィールドに通知する際に行われる通信がある。また、ステップS2500 での関係性を収集する際に行われる通信、計画システムと結合部との間で行われる通信がある。
上記の通信の内容が匿名化された例を図48〜図50に示す。図48は、管理フィールドの探索の要求時および返答時に送受信される通信内容の他の一例を示す説明図である。図48(a)は、管理フィールドの探索の要求メッセージを示す。また、図48(b)は、管理フィールドの探索の要求に対する返答メッセージを示す。図48に示すように、状態要素の情報が匿名化されている。
図49は、関係性の収集の要求時および返答時に送受信される通信内容の他の一例を示す説明図である。図49(a)は、関係性の収集の要求メッセージを示す。また、図49(b)は、関係性の収集の要求に対する返答メッセージを示す。図49に示すように、状態要素の情報や事前状態制約の情報等が匿名化されている。
図50は、協調部と結合部との間で送受信される通信内容の他の一例を示す説明図である。図50(a)は、協調部から結合部に送信される要求メッセージを示す。また、図50(b)は、結合部から協調部に送信される返答メッセージを示す。図50に示すように、事前状態制約の情報等が匿名化されている。
[効果の説明]
本実施形態の方法が使用されると、複数の管理ドメインそれぞれで管理されるシステムが関連する場合であっても計画システムが利用される。利用者は、各管理ドメイン内で及ぶ影響を確認した上で、システム構成を変更できる。
また、本実施形態の計画システムは、複数の管理ドメインそれぞれで管理されるシステムが関連する場合であっても、高級なシステム構成定義を用いてシステム構成の変更手順を生成できる。その理由は、コンパイル部104が高級なシステム構成定義を、調整部103が処理できる低級なシステム構成定義に変換できるためである。
なお、各実施形態の計画システム100、計画システム100a、他の計画システム110、および結合部120は、例えば、記憶媒体に格納されているプログラムに従って処理を実行するCPU(Central Processing Unit)によって実現される。すなわち協調部101、計画部102、調整部103、およびコンパイル部104は、例えば、プログラム制御に従って処理を実行するCPU によって実現される。
また、各実施形態の計画システム100、および計画システム100aにおける各部は、ハードウェア回路によって実現されてもよい。一例として、協調部101、計画部102、調整部103、およびコンパイル部104が、それぞれLSI(Large Scale Integration)で実現される。また、それらが1つのLSI で実現されていてもよい。
次に、本発明の概要を説明する。図51は、本発明による協調計画システムの概要を示すブロック図である。本発明による協調計画システム10は、システム構成をそれぞれ管理する複数の計画システム201〜20N(例えば、計画システム100)と、複数のシステム構成の変更要求に対する変更手順を生成する生成部30(例えば、結合部120)とを含む協調計画システムであって、生成部30は、複数の計画システム201〜20Nから入力された複数のシステム構成の定義を基に変更手順を生成し、生成された変更手順を各システム構成の要素に関する手順ごとに分割することによって複数の部分的な手順を生成し、実行が完了すると第2の部分的な手順に含まれる第2の手順の実行が開始される第1の手順を含む第1の部分的な手順に対して第2の部分的な手順を実行する計画システムに手順の完了を示す情報を入力する手順を第1の手順の後に追加し、第2の部分的な手順に対して第1の部分的な手順を実行する計画システムから手順の完了を示す情報が入力される手順を第2の手順の前に追加する。
そのような構成により、協調計画システムは、複数の管理ドメインに影響を及ぼすシステムの構成変更の手順を各管理ドメイン内で生成される部分的な手順の集合として生成できる。
また、計画システム201〜20Nは、管理対象のシステム構成の定義を加工した上で生成部30に入力する入力部(例えば、協調部101)を含み、入力部は、複数のシステム構成の変更要求に基づいて管理対象のシステム構成の定義から変更対象の部分を抽出し、抽出された変更対象の部分を生成部30に入力してもよい。
そのような構成により、協調計画システムは、機密性のより高い状態でシステム構成の変更手順をより高速に生成できる。
また、入力部は、抽出された変更対象の部分を1つ以上の強連結成分に分解した上で生成部30に入力してもよい。
そのような構成により、協調計画システムは、システム構成の変更手順をより高速に生成できる。
また、入力部は、管理対象のシステム構成の定義の内容を匿名化した上で生成部30に入力してもよい。
そのような構成により、協調計画システムは、機密性のより高い状態でシステム構成の変更手順を生成できる。
また、生成部30は、生成された複数の部分的な手順を各計画システム201〜20Nの入力部にそれぞれ入力し、入力部には、入力された部分的な手順の実行に要する情報が他の計画システムから入力されてもよい。
そのような構成により、協調計画システムは、計画システム同士が協調した状態でシステム構成を変更できる。
また、入力部は、入力された部分的な手順に含まれる匿名化された情報を元の情報に変換してもよい。
そのような構成により、協調計画システムは、機密性のより高い状態でシステム構成を変更できる。
また、管理対象のシステム構成の定義は、1つ以上のシステム構成の要素群と要素間の関係性を含む定義情報であるコンポネントと、コンポネントが他のコンポネントと接続されるための点を示す定義情報であるポートと、ポート間の接続に関する定義情報であるワイヤとを含む高級なシステム構成定義であり、計画システム201〜20Nは、高級なシステム構成定義を要素群と要素間の関係性とで構成される低級なシステム構成定義に変換する変換部(例えば、コンパイル部104)を含んでもよい。
そのような構成により、協調計画システムは、手動でより容易に生成されるシステム構成定義を基にシステム構成の変更手順を生成できる。
また、計画システム201〜20Nが管理する高級なシステム構成定義は、他の計画システムが管理する高級なシステム構成定義内のポートの情報を含んでもよい。
そのような構成により、協調計画システムは、複数の管理ドメインに跨る高級なシステム構成定義を基にシステム構成の変更手順を生成できる。
なお、計画システム201〜20Nと生成部30は、通信ネットワークを介して通信可能に接続されていてもよい。また、計画システム201〜20Nは、外部の入出力装置および記憶装置と通信ネットワークを介して通信可能に接続されていてもよい。また、入力部は、他の計画システムと通信ネットワークを介して通信可能に接続されていてもよい。
また、計画システム201〜20Nは、入出力装置を介して利用者からシステム構成の変更要求を受け付けた時に、入力部を介して関連する全ての計画システムと通信し、いずれかの計画システムを生成部30として利用することによって手順計画を実行してもよい。
例えば、システム構成の変更要求を受け付けた計画システムが生成部30として利用されてもよいし、一度各計画システム201〜20Nが管理する状態要素の数が確認された上で最も多くの状態要素を管理する計画システムが生成部30として利用されてもよい。
生成部30として利用される計画システムは、各計画システム201〜20Nから状態要素を収集し、手順計画を実行し、実行結果を分割することによって部分的な手順を生成し、生成された部分的な手順を各計画システム201〜20Nに返信する。
また、各計画システム201〜20Nが管理するシステム構成の定義には、1つ以上の構成要素とシステム構成の定義間の関係性とが含まれ、各構成要素は、構成要素が取り得る1つ以上の状態と実行可能な状態遷移の情報を含み、システム構成の定義間の関係性は、少なくともシステム構成の定義内の構成要素の状態遷移が実行される事前制約としての他のシステム構成の定義内の構成要素の状態の指定、システム構成の定義内の条件判断に要する他のシステム構成の定義内の構成要素の指定、システム構成の定義内の構成要素を制御する他のシステム構成の定義内の制御モジュールの指定のいずれかを表してもよい。
また、複数の計画システム201〜20Nのうちのいずれか1つの計画システムが、他の計画システムに対して生成部30に入力されるシステム構成の定義を指定してもよい。
以上、実施形態および実施例を参照して本願発明を説明したが、本願発明は上記実施形態および実施例に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。
この出願は、2016年10月20日に出願された日本特許出願2016−205841を基礎とする優先権を主張し、その開示の全てをここに取り込む。
また、上記の実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下に限られない。
(付記1)システム構成をそれぞれ管理する複数の計画システムと、複数のシステム構成の変更要求に対する変更手順を生成する生成部とを含む協調計画システムであって、前記生成部は、前記複数の計画システムから入力された複数のシステム構成の定義を基に前記変更手順を生成し、生成された前記変更手順を各システム構成の要素に関する手順ごとに分割することによって複数の部分的な手順を生成し、実行が完了すると第2の部分的な手順に含まれる第2の手順の実行が開始される第1の手順を含む第1の部分的な手順に対して前記第2の部分的な手順を実行する計画システムに手順の完了を示す情報を入力する手順を前記第1の手順の後に追加し、前記第2の部分的な手順に対して前記第1の部分的な手順を実行する計画システムから前記手順の完了を示す情報が入力される手順を前記第2の手順の前に追加することを特徴とする協調計画システム。
(付記2)計画システムは、管理対象のシステム構成の定義を加工した上で生成部に入力する入力部を含み、前記入力部は、複数のシステム構成の変更要求に基づいて前記管理対象のシステム構成の定義から変更対象の部分を抽出し、抽出された前記変更対象の部分を前記生成部に入力する付記1記載の協調計画システム。
(付記3)入力部は、抽出された変更対象の部分を1つ以上の強連結成分に分解した上で生成部に入力する付記2記載の協調計画システム。
(付記4)入力部は、管理対象のシステム構成の定義の内容を匿名化した上で生成部に入力する付記2または付記3記載の協調計画システム。
(付記5)生成部は、生成された複数の部分的な手順を各計画システムの入力部にそれぞれ入力し、前記入力部には、入力された部分的な手順の実行に要する情報が他の計画システムから入力される付記2から付記4のうちのいずれか1項に記載の協調計画システム。
(付記6)入力部は、入力された部分的な手順に含まれる匿名化された情報を元の情報に変換する付記5記載の協調計画システム。
(付記7)管理対象のシステム構成の定義は、1つ以上の前記システム構成の要素群と要素間の関係性を含む定義情報であるコンポネントと、コンポネントが他のコンポネントと接続されるための点を示す定義情報であるポートと、ポート間の接続に関する定義情報であるワイヤとを含む高級なシステム構成定義であり、計画システムは、前記高級なシステム構成定義を要素群と要素間の関係性とで構成される低級なシステム構成定義に変換する変換部を含む付記1から付記6のうちのいずれか1項に記載の協調計画システム。
(付記8)計画システムが管理する高級なシステム構成定義は、他の計画システムが管理する高級なシステム構成定義内のポートの情報を含む付記7記載の協調計画システム。
(付記9)システム構成をそれぞれ管理する複数の計画システムを含み、複数のシステム構成の変更要求に対する変更手順を生成する協調計画システムにおいて実行される協調計画方法であって、前記複数の計画システムから入力された複数のシステム構成の定義を基に前記変更手順を生成し、生成された前記変更手順を各システム構成の要素に関する手順ごとに分割することによって複数の部分的な手順を生成し、実行が完了すると第2の部分的な手順に含まれる第2の手順の実行が開始される第1の手順を含む第1の部分的な手順に対して前記第2の部分的な手順を実行する計画システムに手順の完了を示す情報を入力する手順を前記第1の手順の後に追加し、前記第2の部分的な手順に対して前記第1の部分的な手順を実行する計画システムから前記手順の完了を示す情報が入力される手順を前記第2の手順の前に追加することを特徴とする協調計画方法。
(付記10)システム構成をそれぞれ管理する複数の計画システムを含み、複数のシステム構成の変更要求に対する変更手順を生成するコンピュータにおいて実行される協調計画プログラムであって、前記コンピュータに、前記複数の計画システムから入力された複数のシステム構成の定義を基に前記変更手順を生成する第1生成処理、生成された前記変更手順を各システム構成の要素に関する手順ごとに分割することによって複数の部分的な手順を生成する第2生成処理、実行が完了すると第2の部分的な手順に含まれる第2の手順の実行が開始される第1の手順を含む第1の部分的な手順に対して前記第2の部分的な手順を実行する計画システムに手順の完了を示す情報を入力する手順を前記第1の手順の後に追加する第1追加処理、および前記第2の部分的な手順に対して前記第1の部分的な手順を実行する計画システムから前記手順の完了を示す情報が入力される手順を前記第2の手順の前に追加する第2追加処理を実行させるための協調計画プログラム。
(付記11)複数のシステム構成の変更要求に対する変更手順を生成する生成部を備える協調計画装置であって、前記生成部は、システム構成をそれぞれ管理する複数の計画システムから入力された複数のシステム構成の定義を基に前記変更手順を生成し、生成された前記変更手順を各システム構成の要素に関する手順ごとに分割することによって複数の部分的な手順を生成し、実行が完了すると第2の部分的な手順に含まれる第2の手順の実行が開始される第1の手順を含む第1の部分的な手順に対して前記第2の部分的な手順を実行する計画システムに手順の完了を示す情報を入力する手順を前記第1の手順の後に追加し、前記第2の部分的な手順に対して前記第1の部分的な手順を実行する計画システムから前記手順の完了を示す情報が入力される手順を前記第2の手順の前に追加することを特徴とする協調計画装置。