特許 7578187 通信システム、検査装置、検査方法、及びプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-10-28

(45)【発行日】2024-11-06

(54)【発明の名称】通信システム、検査装置、検査方法、及びプログラム

(51)【国際特許分類】

   G06F 21/50 20130101AFI20241029BHJP

【ＦＩ】

G06F21/50

【請求項の数】 8

(21)【出願番号】P 2023510124

(86)(22)【出願日】2021-04-01

(86)【国際出願番号】 JP2021014231

(87)【国際公開番号】W WO2022208857

(87)【国際公開日】2022-10-06

【審査請求日】2023-09-22

(73)【特許権者】

【識別番号】000004226

【氏名又は名称】日本電信電話株式会社

(74)【代理人】

【識別番号】110004381

【氏名又は名称】弁理士法人ＩＴＯＨ

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100124844

【弁理士】

【氏名又は名称】石原 隆治

(72)【発明者】

【氏名】白石 将浩

(72)【発明者】

【氏名】長山 弘樹

(72)【発明者】

【氏名】鷲尾 知暁

(72)【発明者】

【氏名】宮島 麻美

【審査官】塩澤 如正

(56)【参考文献】

【文献】国際公開第２０１４／２０３７２８（ＷＯ，Ａ１）

【文献】特開２０１５－０４３２０８（ＪＰ，Ａ）

【文献】特開２０１５－２３２８２０（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ ２１／５０

(57)【特許請求の範囲】

【請求項1】

ブローカレス型の出版／購読型モデルにより複数のノード間で通信を行う通信システムであって、
１以上の前記ノード上で冗長化された１以上のアプリケーションであって、出版側として機能する１以上のアプリケーションのうち、購読側で優先的に扱われる一のアプリケーションに異常が発生したと見做して前記一のアプリケーションに対する検査指示を受け付ける検査管理部と、
前記検査指示に基づいて、前記購読側で優先的に扱われるアプリケーションを、前記１以上のアプリケーションのうち、前記一のアプリケーションとは異なる他のアプリケーションに切り替えるための検査用コマンドを前記ノードに送信する検査指示出力部と、
を有する通信システム。

【請求項2】

前記検査管理部は、
前記通信システムのネットワーク構成を表す構成情報と、予め作成された検査リストとをユーザに提示し、前記ユーザから、前記一のアプリケーションに対する検査指示を受け付ける、請求項１に記載の通信システム。

【請求項3】

前記構成情報は、
前記通信の送受信に関する前記ノード間の関係性を表す第１の関係性情報と、所属ドメイン及び出版側若しくは購読側のいずれであるかに関する前記ノード間の関係性を表す第２の関係性情報と、出版及び購読されるトピックに関する前記ノード間の関係性を表す第３の関係性情報とを用いて、ＩＰアドレス及びポート番号により前記第１の関係性情報と前記第２の関係性情報を関連付けるとともに、前記出版／購読型モデルで利用される識別子により前記第２の関係性情報と前記第３の関係性情報とを関連付けた情報である、請求項２に記載の通信システム。

【請求項4】

ブローカレス型の出版／購読型モデルにより通信を行う複数のノードと接続される検査装置であって、
１以上の前記ノード上で冗長化された１以上のアプリケーションであって、出版側として機能する１以上のアプリケーションのうち、購読側で優先的に扱われる一のアプリケーションに異常が発生したと見做して前記一のアプリケーションに対する検査指示を受け付ける検査管理部と、
前記検査指示に基づいて、前記購読側で優先的に扱われるアプリケーションを、前記１以上のアプリケーションのうち、前記一のアプリケーションとは異なる他のアプリケーションに切り替えるための検査用コマンドを前記ノードに送信する検査指示出力部と、
を有する検査装置。

【請求項5】

前記検査管理部は、
前記複数のノードで構成される通信システムのネットワーク構成を表す構成情報と、予め作成された検査リストとをユーザに提示し、前記ユーザから、前記一のアプリケーションに対する検査指示を受け付ける、請求項４に記載の検査装置。

【請求項6】

前記構成情報は、
前記通信の送受信に関する前記ノード間の関係性を表す第１の関係性情報と、所属ドメイン及び出版側若しくは購読側のいずれであるかに関する前記ノード間の関係性を表す第２の関係性情報と、出版及び購読されるトピックに関する前記ノード間の関係性を表す第３の関係性情報とを用いて、ＩＰアドレス及びポート番号により前記第１の関係性情報と前記第２の関係性情報を関連付けるとともに、前記出版／購読型モデルで利用される識別子により前記第２の関係性情報と前記第３の関係性情報とを関連付けた情報である、請求項５に記載の検査装置。

【請求項7】

ブローカレス型の出版／購読型モデルにより通信を行う複数のノードと接続される検査装置が、
１以上の前記ノード上で冗長化された１以上のアプリケーションであって、出版側として機能する１以上のアプリケーションのうち、購読側で優先的に扱われる一のアプリケーションに異常が発生したと見做して前記一のアプリケーションに対する検査指示を受け付ける検査管理手順と、
前記検査指示に基づいて、前記購読側で優先的に扱われるアプリケーションを、前記１以上のアプリケーションのうち、前記一のアプリケーションとは異なる他のアプリケーションに切り替えるための検査用コマンドを前記ノードに送信する検査指示出力手順と、
を実行する検査方法。

【請求項8】

コンピュータを、請求項４乃至６の何れか一項に記載の検査装置として機能させるプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、Ｐｕｂ／Ｓｕｂ通信を行う通信システムにおけるＰｕｂ側の冗長化構成を検査する技術に関する。

【背景技術】

【0002】

近年、スマートファクトリーの実現に向け、情報ＮＷ（ネットワーク）上の機器とコントロールＮＷ上の機器とを繋ぐことから進められている。今後、機器の相互接続、１対多、多対１の通信を軽量・柔軟に行う通信モデルの普及が想定される。

【0003】

上記のような軽量・柔軟に行う通信モデルとしてＰｕｂｌｉｓｈ／Ｓｕｂｓｃｒｉｂｅ通信（以降、Ｐｕｂ／Ｓｕｂ通信）モデルが提案されている。Ｐｕｂ／Ｓｕｂ通信では、ｅｖｅｎｔと呼ばれるメッセージを作成して送信（配信）する側のクライアントであるＰｕｂｌｉｓｈｅｒと、メッセージを受信（購読）する側のクライアントであるＳｕｂｓｃｒｉｂｅｒが存在する。

【0004】

Ｐｕｂ／Ｓｕｂ通信には、「空間的分離」、「時間的分離」、「非同期処理」という３つの性質がある。「空間的分離」により、ＰｕｂｌｉｓｈｅｒとＳｕｂｓｃｒｉｂｅｒは互いの存在を知る必要がない。「時間的分離」により、ＰｕｂｌｉｓｈｅｒとＳｕｂｓｃｒｉｂｅｒが同時にネットワーク上に存在しなくてもデータの送受信が可能である。また、「非同期処理」により、ｅｖｅｎｔの送信、受信はＰｕｂｌｉｓｈｅｒもしくはＳｕｂｓｃｒｉｂｅｒのその他の処理と非同期で処理することができる。

【0005】

Ｐｕｂ／Ｓｕｂ通信モデルには、ブローカ型とブローカレス型がある。ブローカ型の構成は、空間的分離、時間的分離、及び非同期処理の性質を担うブローカと呼ばれる機能をＰｕｂとＳｕｂの間に配置した構成である。ブローカレス型の構成は、全てのノード（ＰｕｂとＳｕｂ）が空間的分離、時間的分離、及び非同期処理の性質を担う機能を持った分散構成である。各ノードに、ＤＤＳ（Ｄａｔａ Ｄｉｓｔｒｉｂｕｔｉｏｎ Ｓｅｒｖｉｃｅ）と呼ばれる機能を配備することで、上記のブローカレス型の構成を実現することができる。なお、Ｐｕｂ／Ｓｕｂ通信モデルは出版／購読型モデルとも呼ばれる。

【先行技術文献】

【非特許文献】

【0006】

【文献】What's in the DDS Standard, インターネット＜ＵＲＬ：https://www.dds-foundation.org/omg-dds-standard/＞

【発明の概要】

【発明が解決しようとする課題】

【0007】

ＤＤＳを用いたＰｕｂ／Ｓｕｂ通信を行う通信システムでは、ＤＤＳの基本的な機能によりＰｕｂを冗長化することが可能であり、例えば、冗長化構成の複数のＰｕｂのうちいずれのＰｕｂを優先的なＰｕｂ（以降、優先Ｐｕｂ）と扱うかを切り替えることができる。

【0008】

しかしながら、例えば、何等かの理由によって実際には優先Ｐｕｂが想定通りに切り替わらない事態もあり得る。このため、優先Ｐｕｂが想定通りに切り替わることを事前に検査しておくことが望ましい。

【0009】

本発明は上記の点に鑑みてなされたものであり、Ｐｕｂ／Ｓｕｂ通信を行う通信システムにおいて、Ｐｕｂ側の冗長化構成を検査する技術を提供することを目的とする。

【課題を解決するための手段】

【0010】

開示の技術によれば、ブローカレス型の出版／購読型モデルにより複数のノード間で通信を行う通信システムであって、
１以上の前記ノード上で冗長化された１以上のアプリケーションであって、出版側として機能する１以上のアプリケーションのうち、購読側で優先的に扱われる一のアプリケーションに対する検査指示を受け付ける検査管理部と、
前記一のアプリケーションに対して異常を挿入することで、前記購読側で優先的に扱われるアプリケーションを、前記１以上のアプリケーションのうち、前記一のアプリケーションとは異なる他のアプリケーションに切り替えることを検査する検査指示出力部と、
を有する通信システムが提供される。

【発明の効果】

【0011】

開示の技術によれば、Ｐｕｂ／Ｓｕｂ通信を行う通信システムにおいて、Ｐｕｂ側の冗長化構成を検査する技術が提供される。

【図面の簡単な説明】

【0012】

【図1】ＤＤＳを用いたＰｕｂ／Ｓｕｂ通信を説明するための図である。

【図2】ＤＤＳが組み込まれるシステム構成例を示す図である。

【図3】複数ノードを有するシステムの構成例を示す図である。

【図4】実施例の概要を説明するための図である。

【図5】実施例におけるシステム構成例を示す図である。

【図6】構成管理を説明するための図である。

【図7】実施例における構成管理部の構成例を示す図である。

【図8】実施例における対処部の構成例を示す図である。

【図9】実施例におけるＤＤＳ操作機能部の構成例を示す図である。

【図10】実施例における処理フローを示す図である。

【図11】装置のハードウェア構成例を示す図である。

【発明を実施するための形態】

【0013】

以下、図面を参照して本発明の実施の形態（本実施の形態）を説明する。以下で説明する実施の形態は一例に過ぎず、本発明が適用される実施の形態は、以下の実施の形態に限られるわけではない。

【0014】

以下で説明する実施形態では、本発明を、ＤＤＳを用いたＰｕｂ／Ｓｕｂ通信を行う通信システムに適用する例を説明するが、本発明は、ＤＤＳを用いたＰｕｂ／Ｓｕｂ通信に限らずに適用可能である。

【0015】

（ＤＤＳを用いたＰｕｂ／Ｓｕｂ通信について）
まず、本実施の形態の前提となるＤＤＳ、及びＤＤＳを用いたＰｕｂ／Ｓｕｂ通信について説明する。

【0016】

本実施の形態では、前述したブローカレス型の構成を採用しており、ＤＤＳが、ブローカに相当する機能を担うことにより、ブローカレス型を実現している。

【0017】

ここで、ＤＤＳにおける配送範囲管理について説明する。ＤＤＳではノードが持つＮＷ Ｉ／Ｆに配送用ＮＷを追加する。利用者が設定した配送範囲はこの配送用ＮＷとＤＤＳ内部のフィルタにより動作し、Ｐｕｂ又はＳｕｂとして機能するアプリケーションに適切なデータの送受信を可能にする。

【0018】

具体的には、データバスと利用者が設定する配送範囲をもとに、ＤＤＳではノードの中で利用できるＮＷ Ｉ／Ｆにマルチキャストアドレスを付与し、配送用ＮＷを整備する。配送範囲指定時にノードが既存で持つＩＰアドレスを利用したユニキャストで配信するか、新たに付与したマルチキャストアドレスを活用するかについても設定でき、物理的なデータ流通範囲を定めることを可能にしている。

【0019】

図１に配送範囲の一例を示す。図１の例では、配送範囲として、ドメインＡとドメインＢが設定されている。また、ドメインＡ内において、トピック［い］についての配送範囲とトピック［ろ］についての配送範囲が設定されている。また、トピック［い］の配送範囲内において、キー［ＩＩ］の配送範囲が設定されている。

【0020】

（ＤＤＳが組み込まれるシステム構成例について）
ＤＤＳは、ノード（コンピュータ、通信装置などと呼んでもよい）においてミドルウェアとして機能するプログラムである。ＤＤＳにおける通信に必要な大元となる処理プログラムはライブラリとして用意されている。アプリケーション（「ＡＰＰ」と記述する）が送信するデータの定義（型、サイズ、名称、ＱｏＳ、など）をパラメータとして有する通信プログラム生成用データ定義ファイルから、このライブラリを利用することで、ＤＤＳのプログラムを生成することができる。ＤＤＳの生成自体は既存技術である。

【0021】

図２は、ＤＤＳが組み込まれるシステム構成例を示す図である。図２は、物理的には、センサや制御バルブが接続された複数のノード（コンピュータ）が、論理的なバス型のネットワークに接続された構成を示している。

【0022】

ノード１、２にはそれぞれセンサが接続されており、Ｐｕｂｌｉｓｈするデータを生成するＡＰＰと、ＤＤＳが搭載されている。ノード２、３にはそれぞれ制御バルブが接続されており、Ｓｕｂｓｃｒｉｂｅしたデータを活用するＡＰＰと、ＤＤＳが搭載されている。

【0023】

図２の例は、ＤＤＳにより、冗長化ＱｏＳ設定のあるＰｕｂ／Ｓｕｂ構成を実現した例を示している。具体的には、ノード１のＤＤＳにより主Ｐｕｂと副１Ｐｕｂが構成され、ノード２のＤＤＳにより副２Ｐｕｂが構成されている。また、ノード３のＤＤＳにより第１Ｓｕｂと第２Ｓｕｂが構成され、ノード４のＤＤＳにより第３Ｓｕｂが構成されている。

【0024】

なお、図２の例では、ＡＰＰがｐｙｔｈｏｎで記述され、ＤＤＳがＣ＋＋で記述されている例を示しているが、これらは一例であり、どのようなプログラミング言語で記述されていてもよい。また、Ｐｕｂ／Ｓｕｂ構成の変更をする場合、ＱｏＳなど一部動的に変更できるものと、プロセスの再起動（プログラムの修正を含む）を必要とするものとがある。

【0025】

以下、本実施の形態に係る技術の一例として、実施例について説明する。

【0026】

（本実施例においてベースとなるシステム構成例）
次に、本実施例においてベースとなる通信システムの例について説明する。本実施例においてベースとなる通信システムでは、１つのノードは複数のドメインに所属してよい。また、１つのノードに複数のＰｕｂ／Ｓｕｂが存在してよい。なお、ここでのＰｕｂとはＰｕｂｌｉｓｈするデータを生成するアプリケーションであり、ＳｕｂとはＳｕｂｓｃｒｉｂｅしたデータを活用するアプリケーションである。Ｐｕｂ／Ｓｕｂ通信に係る機能はＤＤＳが担う。

【0027】

また、１つのノードにＰｕｂ／Ｓｕｂの両方が存在してもよく、１つのノードに複数のドメインに跨るＰｕｂ／Ｓｕｂが存在してもよい。また、１つのＡＰＰに複数のＰｕｂ又は複数のＳｕｂが存在してもよい。また、同一ＡＰＰにおける各Ｐｕｂ、各Ｓｕｂは識別可能である。また、本実施例における通信システムでは、通信は平文である。

【0028】

図３に、本実施例においてベースとなる通信システムの構成例を示す。図３に示すように、この通信システムは、ノード１０～１８、Ｌ２ＳＷ（レイヤ２スイッチ）２０、２１、Ｌ３ＳＷ（レイヤ３スイッチ）３０、パケット分析装置４０、検知部５０を有する。

【0029】

図３の例において、ノード１０、１１、１２、１５、１６、１７はドメインＤ１に属し、ノード１２、１３、１７、１８はドメインＤ２に属している。例えば、ノード１０の「ＤＤＳ＿Ｄ１」のＤ１のように、そのノードが属するドメインが示されている。ノード１２とノード１７は、ドメインＤ１とドメインＤ２の両方に属している。

【0030】

例えば、ノード１０において、「Ｐｕｂ１（ＡＰＰい）」は、トピック［い］のデータをＰｕｂｌｉｓｈするアプリケーションであり、Ｐｕｂ／Ｓｕｂ通信においてＰｕｂ１（Ｐｕｂｌｉｓｈｅｒ１）として機能する。ノード１０において、Ｐｕｂ１（ＡＰＰい）とＰｕｂ２（ＡＰＰい）として、２つのＰｕｂが存在する。これは、ＡＰＰとしては１つであるが、ＤＤＳの機能により、２つのＰｕｂとして機能することを示している。ノード１５において示されるように、Ｓｕｂについても同様である。

【0031】

また、ノード１１は、Ｐｕｂ３とＳｕｂ４として、ＰｕｂとＳｕｂの両方を備えている。ノード１２、１４には複数のＰｕｂとして機能する複数のＡＰＰが存在し、ノード１７、１８には複数のＳｕｂとして機能する複数のＡＰＰが存在する。

【0032】

また、図３に示す通信システムにおいては、Ｐｕｂ１（ＡＰＰい）～Ｐｕｂ４（ＡＰＰい）が存在し、「ＡＰＰい」のＰｕｂが冗長化されている。同様に、Ｐｕｂ５（ＡＰＰろ）～Ｐｕｂ６（ＡＰＰろ）が存在し、「ＡＰＰろ」のＰｕｂも冗長化されている。

【0033】

また、Ｌ３ＳＷ３０の先にはインターネット５５が接続されており、各ノードはインターネット５５と通信することが可能である。また、Ｌ２ＳＷ２０、２１には、パケット分析装置４０が接続されており、パケット分析結果に基づいて、検知部５０が異常検知を行うことが可能である。

【0034】

（本実施例の概要）
例えば、或るトピックに関して、第１Ｐｕｂ、第２Ｐｕｂ、第３Ｐｕｂの３つで冗長化されており、第１Ｓｕｂ～第３Ｓｕｂの各Ｓｕｂが第１Ｐｕｂを優先Ｐｕｂと扱っている場合を考える。この場合、各Ｓｕｂには第１Ｐｕｂ～第３Ｐｕｂの各々からデータが配信されるが、第１Ｐｕｂから配信されたデータのみがＳｕｂ側のＡＰＰに渡される。

【0035】

本実施例においては、第１Ｐｕｂに異常などが発生した場合、各Ｓｕｂは、優先Ｐｕｂを第２Ｐｕｂ又は第３Ｐｕｂに切り替えることができるものとする。なお、異常とはＰｕｂの故障の他、例えば、Ｐｕｂが第三者に乗っ取られた結果、不正な内容のデータ（例えば、Ｓｕｂに対する攻撃を目的とするデータなど）を送信しているような場合や不正な状態となっている場合なども含まれるものとする。

【0036】

図４に、上記の優先Ｐｕｂの切り替えの様子を示す。図４の例では、優先Ｐｕｂである第１Ｐｕｂに異常が発生した場合に、優先Ｐｕｂを第３Ｐｕｂに切り替える様子を表している。この切り替えにより、各Ｓｕｂでは第３Ｐｕｂから配信されたデータがＡＰＰに渡されるようになる。

【0037】

本実施例では、疑似的な異常を挿入等することにより、上記の優先Ｐｕｂの切り替えが正しく行われることを検査することができる仕組みが提供される。これにより、例えば、「冗長化構成を組んだつもりが実際の異常時には優先Ｐｕｂが切り替わらなかった」などいった事態の発生を防止することが可能となる。

【0038】

（本実施例におけるシステム構成例）
図５に、本実施例における通信システムの構成例を示す。図５に示すように、図３に示したベースとなる通信システムに対して、各ノードにＤＤＳ操作機能部が備えられ、また、構成管理部６０、対処部７０を有する。ＤＤＳ操作機能部は対処部７０からの指示に応じて優先Ｐｕｂを切り替える機能を実現する。図５では、ノード１０～１８がそれぞれＤＤＳ操作機能部１０１～１０９を備えている例を示している。以降、ノードを区別しない場合は、ＤＤＳ操作機能部１００と表記する。

【0039】

構成管理部６０は通信システムの構成情報（ＮＷ構成情報）を管理し、対処部７０は検査指示に応じて優先Ｐｕｂの切り替え検査を実行する。図５の例では検知部５０が存在するが、優先Ｐｕｂの切り替え検査時には検知部５０は不要である。実際の運用時には、検知部５０による異常検知に応じて優先Ｐｕｂの切り替えが行われる。なお、検知部５０、構成管理部６０、対処部７０はパケット分析装置４０が有していてもよいし、パケット分析装置４０とは異なる装置が有していてもよい。本実施例では、パケット分析装置４０が検知部５０、構成管理部６０、対処部７０を有しているものとする。

【0040】

（構成管理について）
優先Ｐｕｂの切り替え検査を行うためには通信システムの構成情報が管理されている必要がある。これは、通信システム上の検査箇所（例えば、疑似的な異常を発生させるＰｕｂなど）を指定する必要があるためである。このような構成情報な任意の方法で作成及び管理されればよいが、本実施例では、ノード間を流れる通信（トラヒック）から作成できる複数の関係性情報を組み合わせることで、構成情報を作成及び管理するものとする。

【0041】

関係性情報としては、ＮＷの水平軸のトポロジを表す「ＩＰ関係レイヤ」、「参加者関係レイヤ」、「Ｐｕｂ／Ｓｕｂ関係レイヤ」の３つを作成する。ＩＰ関係レイヤと参加者関係レイヤが関連付けられ、参加者関係レイヤとＰｕｂ／Ｓｕｂ関係レイヤが関連付けられるため、結局３つの全てのレイヤが関連付けられることなり、これら３つのレイヤを合成することで、ＮＷの垂直軸のトポロジを表す「合成レイヤ」が得られる。この合成レイヤを複数世代分保持することで、構成情報が管理される。なお、世代とは、例えば、或る時間区切り、イベントの区切りなどで分けた区分を指す。ただし、複数世代分保持することは必須ではなく、例えば、最新の１世代分のみを保持してもよい。

【0042】

図６に、ＩＰ関係レイヤ、参加者関係レイヤ、Ｐｕｂ／Ｓｕｂ関係レイヤ、合成レイヤの一例を示す。図６に示すように、ＩＰ関係レイヤはＩＰアドレスを頂点、ＩＰレベルのデータの送受信関係を枝とするグラフ構造で表される。ＩＰ関係レイヤにおいて、頂点間に枝がある場合はその頂点が表すＩＰアドレスを持つノード間でデータの送受信関係があることを表している。なお、１つのノードが複数のＩＰアドレスを持つことがある（例えば、ユニキャスト用のＩＰアドレスに加えて、マルチキャスト用のＩＰアドレスを持つことがある。）。参加者関係レイヤはノードが持つＧＵＩＤを１つの記号（三角形又は逆三角形の記号）で表しており、各記号は各ＧＵＩＤが属するドメインとＰｕｂ又はＳｕｂのいずれであるかを表している。Ｐｕｂ／Ｓｕｂ関係レイヤはノードが持つＧＵＩＤを頂点、同一トピックに属するか否かの関係を枝としており、各ＧＵＩＤが属するトピックの関係性を表している。なお、参加者関係レイヤも上記の記号（三角形又は逆三角形の記号）を頂点とするグラフ構造で表される。図６の例では参加者関係レイヤを表すグラフ構造には枝がないが、例えば、同一ドメインに属する頂点同士を枝で繋いで表現されてもよい。

【0043】

Ｐｕｂ／Ｓｕｂ関係レイヤはデータ配信としての通信から取得される情報で作成可能であり、参加者関係レイヤはＤＤＳ動作用通信から取得される情報で作成可能である。一方で、ＩＰ関係レイヤはデータ配信としての通信とＤＤＳ動作用通信の両方から取得される情報で作成可能である。なお、ＤＤＳ動作用通信とは、ノードがＰｕｂ／Ｓｕｂ通信に参加するときに行う通信、他のノードを探索するときに行う通信、配信内容を合意するときに行う通信などのことである。

【0044】

ＩＰ関係レイヤにおいて、１つの頂点には、ノードが持つＩＰアドレスを含む５タプル（ｓｒｃ／ｄｓｔ ＩＰアドレス、ｓｒｃ／ｄｓｔ ｐｏｒｔ番号、ｐｒｏｔｏｃｏｌ番号）が対応付けられている。参加者関係レイヤにおいては、１つの記号（三角形又は逆三角形の記号）にはＧＵＩＤとｐｏｒｔ番号が対応付けられている。Ｐｕｂ／Ｓｕｂ関係レイヤにおいては、１つの頂点にはＧＵＩＤとトピック名が対応付けられている。ＧＵＩＤとはＤＤＳで利用される識別子であり、ＩＰアドレスやｐｏｒｔ番号等から生成される。なお、１つのノードが複数のＧＵＩＤを持つことがある（例えば、１つのノードがＰｕｂとＳｕｂの両方として機能する場合、１つのノードが複数のドメインや複数のトピックに属する場合など）。

【0045】

したがって、ＩＰ関係レイヤと参加者関係レイヤをｐｏｒｔ番号で関連付けることが可能であり、参加者関係レイヤとＰｕｂ／Ｓｕｂ関係レイヤをＧＵＩＤで関連付けることが可能である。これらの関連付けにより３つのレイヤを合成することで、Ｐｕｂ／Ｓｕｂ通信を行う通信システムのＮＷ構成情報として合成レイヤが得られる。この合成レイヤは、例えば、複数世代分保持される。

【0046】

ここで、合成レイヤにおいて、ある１つのノードに着目した場合、このノードにはＩＰ関係レイヤの１以上の頂点（ＩＰアドレスを含む５タプル）が対応し、これら１以上の頂点の各々に対して参加者関係レイヤの１以上の頂点（ｐｏｒｔ番号及びＧＵＩＤ）が関連付けられる。また、参加者関係レイヤの１以上の頂点の各々に対して、Ｐｕｂ／Ｓｕｂ関係レイヤの０以上の頂点（ＧＵＩＤ及びトピック名）が関連付けられる。すなわち、合成レイヤでは、各ノードに対して、当該ノードを頂点とするツリー構造（最上位の階層をＩＰアドレス、次の階層をｐｏｒｔ番号、その次の階層をＧＵＩＤ、最後の階層をトピック名とするツリー構造）が得られ、このツリー構造が垂直軸トポロジを表す。

【0047】

（本実施例における各部の構成例）
本実施例では、上記の構成情報を利用して検査箇所に疑似的な異常を挿入等することにより、優先Ｐｕｂの切り替えが正しく行われることを検査することができる仕組みが提供される。

【0048】

図７は、構成管理部６０の構成例を示す。図７に示すように、構成管理部６０は、可視化部６１０、関係性記録部６２０を有する。関係性記録部６２０には、少なくとも１世代の構成情報（ＩＰ関係レイヤ、参加者関係レイヤ、Ｐｕｂ／Ｓｕｂ関係レイヤ、合成レイヤ）が記録されている。なお、構成情報は、予め作成され、関係性記録部６２０に記録されているものとする。これら各部の動作などについては、後述するシーケンスのところで説明される。

【0049】

図８は、対処部７０の構成例を示す。図８に示すように、対処部７０は、検査管理部７１０、検査指示出力部７２０、検査リスト記録部７３０を有する。これら各部の動作などについては、後述するシーケンスのところで説明される。

【0050】

図９は、ＤＤＳ操作機能部１００の構成例を示す。図９に示すように、ＤＤＳ操作機能部１００は、切替部１１０を有する。切替部１１０の動作については、後述するシーケンスのところで説明される。

【0051】

本実施例では、上記の各部により、検査箇所に疑似的な異常を挿入等することにより、優先Ｐｕｂの切り替えが正しく行われることを検査する。

【0052】

（本実施例のシーケンス例）
次に、図１０のシーケンス図を参照して、本実施例における通信システムの動作例について説明する。

【0053】

検査管理部７１０は、通信システムの構成確認を可視化部６１０に依頼する（Ｓ１０１）。可視化部６１０は、この構成確認に応じて、関係性記録部６２０から現在の構成情報（つまり、最新の世代の構成情報）を検索し、その検索結果として当該構成情報を取得する（Ｓ１０２～Ｓ１０３）。そして、可視化部６１０は、取得した構成情報の可視化情報を作成し、検査管理部７１０に提示する（Ｓ１０４～Ｓ１０５）。可視化情報とは、構成情報が表す通信システム構成を、例えばディスプレイ上などに可視化表示するための情報である。これにより、ユーザは、通信システム構成（つまり、Ｐｕｂ／Ｓｕｂのデータ送受信関係や所属ドメイン、トピック、Ｐｕｂの冗長化構成など）を確認することができる。

【0054】

検査管理部７１０は、検査リストを検査リスト記録部７３０から検索し、その検索結果として検査リストを取得する（Ｓ１０６～Ｓ１０７）。検査リストとは、検査可能な検査箇所のリストである。このような検査リストは、システムの設計書をもとに作成する、あるいは検査実施前までの通信情報をもとに抽出した情報をもとに作成する、といった方法で作成され得るが、本実施例では作成の方法は限定せず、予め作成されていればよい。なお、検査箇所は、例えば、検査対象となる優先ＰｕｂのＩＤや名称、所属ドメイン、トピック、ＱｏＳ情報、このＰｕｂを有するノードのＩＰアドレスなどの組で表される。

【0055】

その後、検査管理部７１０は、検査対象となる検査箇所の指示待ち状態となる（Ｓ１０８）。例えばユーザなどは、可視化された構成情報と検査リストからどのＰｕｂを検査対象とするかを決定することができる。

【0056】

ユーザなどにより検査箇所の指定及び検査指示が行われ、これを受け付けると、検査管理部７１０は、当該検査箇所の検査指示依頼を検査指示出力部７２０に送信する（Ｓ１０９～Ｓ１１０）。ここで指定された検査箇所が、異常が発生したと見做される優先Ｐｕｂである。なお、検査指示の際には、検査種別（例えば、Ｐｕｂが停止したことを示す「停止」、Ｐｕｂの設定が変更されたことを示す「修正」など）が指定されてもよく、また、検査種別が「修正」の場合はその変更内容が指定されてもよい。例えば、Ｐｕｂが故障等により停止した場合の検査を行いたい場合は検査種別「停止」が指定され、Ｐｕｂが第三者に乗っ取られ不正なデータを送信している場合や不正な状態となっている場合の検査を行いたい場合は検査種別「修正」が指定され、その変更内容として不正なデータを送信する内容や不正な状態を表す内容が指定される。

【0057】

不正な状態の具体例を挙げると、例えば、或るノードのＰｕｂはドメインＡのトピック「い」に所属して温度データを送信していることが正常状態であるとする。このとき、当該ノードのＰｕｂをドメインＢに所属している内容に修正した場合、このＰｕｂは不正な状態になっていると言える。

【0058】

ただし、上記の検査種別は一例であって、様々な種別の検査が可能であってもよい。例えば、新たなＰｕｂがＰｕｂ／Ｓｕｂ通信に参加した際の検査を行うような検査種別が存在してもよい。

【0059】

検査指示出力部７２０は、検査指示依頼を受信すると、検査箇所のＰｕｂから他のＰｕｂ（以降、切替先Ｐｕｂ）に優先Ｐｕｂを切り替えるためのコマンド（以降、検査用コマンド）を検査リスト記録部７３０から検索し、その検索結果として当該検査用コマンドを取得する（Ｓ１１１～Ｓ１１２）。なお、切替先Ｐｕｂは検査箇所のＰｕｂと冗長化構成をとっているＰｕｂの中から決定されるが、この際、予め１つのＰｕｂが決められていてもよいし、何等かのルールに従って決定されてもよい。また、検査用コマンドは予め検査リスト記録部７３０に記録されているが、例えば、検査種別に応じて検査用コマンドが検索及び取得されてもよいし、検査種別の他に検査対象のＰｕｂやその所属ドメイン、トピック等に応じて検査用コマンドが検索及び取得されてもよい。

【0060】

続いて、検査指示出力部７２０は、上記の検査用コマンドを切替部１１０に送信する（Ｓ１１３）。なお、検査指示出力部７２０は、切替先Ｐｕｂと、この切替先Ｐｕｂからのデータを受信するＳｕｂの両方の切替部１１０に対して検査用コマンドを送信する。ただし、切替先Ｐｕｂとこの切替先Ｐｕｂからのデータを受信するＳｕｂとでは、検査用コマンドの内容が異なっていてもよい。

【0061】

そして、切替部１１０は、上記の検査用コマンドを受信すると、ＤＤＳへ検査用コマンドを実行する（Ｓ１１４）。なお、このとき、必要に応じてプロセスの再起動なども行う。これにより、検査対象のＰｕｂ（現在の優先Ｐｕｂ）から切替先Ｐｕｂへ優先Ｐｕｂが切り替わるか否かが検査される。

【0062】

（ハードウェア構成例）
本実施の形態におけるＤＤＳ操作機能部１００を有するノードと、検知部５０、構成管理部６０及び対処部７０を有するパケット分析装置４０は、例えば、コンピュータに、本実施の形態で説明する処理内容を記述したプログラムを実行させることにより実現することができる。

【0063】

上記プログラムは、コンピュータが読み取り可能な記録媒体（可搬メモリ等）に記録して、保存したり、配布したりすることが可能である。また、上記プログラムをインターネットや電子メール等、ネットワークを通して提供することも可能である。

【0064】

図１１は、上記コンピュータのハードウェア構成例を示す図である。図１１のコンピュータは、それぞれバスＢで相互に接続されているドライブ装置１０００、補助記憶装置１００２、メモリ装置１００３、ＣＰＵ１００４、インタフェース装置１００５、表示装置１００６、入力装置１００７、出力装置１００８などを有する。

【0065】

当該コンピュータでの処理を実現するプログラムは、例えば、ＣＤ－ＲＯＭ又はメモリカード等の記録媒体１００１によって提供される。プログラムを記憶した記録媒体１００１がドライブ装置１０００にセットされると、プログラムが記録媒体１００１からドライブ装置１０００を介して補助記憶装置１００２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１００１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１００２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。

【0066】

メモリ装置１００３は、プログラムの起動指示があった場合に、補助記憶装置１００２からプログラムを読み出して格納する。ＣＰＵ１００４は、メモリ装置１００３に格納されたプログラムに従って、上記の各部に係る機能を実現する。インタフェース装置１００５は、ネットワークに接続するためのインタフェースとして用いられる。表示装置１００６はプログラムによるＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）などを表示する。入力装置１００７はキーボード及びマウス、ボタン、又はタッチパネル等で構成され、様々な操作指示を入力させるために用いられる。出力装置１００８は演算結果を出力する。なお、ノード又はパケット分析装置４０において、表示装置１００６、入力装置１００７のいずれか又は両方を備えないこととしてもよい。

【0067】

（実施の形態の効果）
本実施の形態に係る技術によれば、Ｐｕｂ／Ｓｕｂ通信を行う通信システムにおけるＰｕｂ側の冗長化構成を検査することが可能となる。

【0068】

（実施の形態のまとめ）
本明細書には、少なくとも下記各項の通信システム、検査装置、検査方法、及びプログラムが開示されている。
（第１項）
ブローカレス型の出版／購読型モデルにより複数のノード間で通信を行う通信システムであって、
１以上の前記ノード上で冗長化された１以上のアプリケーションであって、出版側として機能する１以上のアプリケーションのうち、購読側で優先的に扱われる一のアプリケーションに対する検査指示を受け付ける検査管理部と、
前記一のアプリケーションに対して異常を挿入することで、前記購読側で優先的に扱われるアプリケーションを、前記１以上のアプリケーションのうち、前記一のアプリケーションとは異なる他のアプリケーションに切り替えることを検査する検査指示出力部と、
を有する通信システム。
（第２項）
前記検査管理部は、
前記通信システムのネットワーク構成を表す構成情報と、予め作成された検査リストとをユーザに提示し、前記ユーザから、前記一のアプリケーションに対する検査指示を受け付ける、第１項に記載の通信システム。
（第３項）
前記構成情報は、
前記通信の送受信に関する前記ノード間の関係性を表す第１の関係性情報と、所属ドメイン及び出版側若しくは購読側のいずれであるかに関する前記ノード間の関係性を表す第２の関係性情報と、出版及び購読されるトピックに関する前記ノード間の関係性を表す第３の関係性情報とを用いて、ＩＰアドレス及びポート番号により前記第１の関係性情報と前記第２の関係性情報を関連付けるとともに、前記出版／購読型モデルで利用される識別子により前記第２の関係性情報と前記第３の関係性情報とを関連付けた情報である、第２項に記載の通信システム。
（第４項）
ブローカレス型の出版／購読型モデルにより通信を行う複数のノードと接続される検査装置であって、
１以上の前記ノード上で冗長化された１以上のアプリケーションであって、出版側として機能する１以上のアプリケーションのうち、購読側で優先的に扱われる一のアプリケーションに対する検査指示を受け付ける検査管理部と、
前記一のアプリケーションに対して異常を挿入することで、前記購読側で優先的に扱われるアプリケーションを、前記１以上のアプリケーションのうち、前記一のアプリケーションとは異なる他のアプリケーションに切り替えることを検査する検査指示出力部と、
を有する検査装置。
（第５項）
前記検査管理部は、
前記複数のノードで構成される通信システムのネットワーク構成を表す構成情報と、予め作成された検査リストとをユーザに提示し、前記ユーザから、前記一のアプリケーションに対する検査指示を受け付ける、第４項に記載の検査装置。
（第６項）
前記構成情報は、
前記通信の送受信に関する前記ノード間の関係性を表す第１の関係性情報と、所属ドメイン及び出版側若しくは購読側のいずれであるかに関する前記ノード間の関係性を表す第２の関係性情報と、出版及び購読されるトピックに関する前記ノード間の関係性を表す第３の関係性情報とを用いて、ＩＰアドレス及びポート番号により前記第１の関係性情報と前記第２の関係性情報を関連付けるとともに、前記出版／購読型モデルで利用される識別子により前記第２の関係性情報と前記第３の関係性情報とを関連付けた情報である、第５項に記載の検査装置。
（第７項）
ブローカレス型の出版／購読型モデルにより通信を行う複数のノードと接続される検査装置が、
１以上の前記ノード上で冗長化された１以上のアプリケーションであって、出版側として機能する１以上のアプリケーションのうち、購読側で優先的に扱われる一のアプリケーションに対する検査指示を受け付ける検査管理手順と、
前記一のアプリケーションに対して異常を挿入することで、前記購読側で優先的に扱われるアプリケーションを、前記１以上のアプリケーションのうち、前記一のアプリケーションとは異なる他のアプリケーションに切り替えることを検査する検査指示出力手順と、
を実行する検査方法。
（第８項）
コンピュータを、第４項乃至第６項の何れか一項に記載の検査装置として機能させるプログラム。

【0069】

以上、本実施の形態について説明したが、本発明はかかる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

【符号の説明】

【0070】

１０～１８ ノード
２０、２１ Ｌ２ＳＷ
３０ Ｌ３ＳＷ
４０ パケット分析装置
５０ 検知部
５５ インターネット
６０ 構成管理部
７０ 対処部
１００ ＤＤＳ操作機能部
１１０ 切替部
６１０ 可視化部
６２０ 関係性記録部
７１０ 検査管理部
７２０ 検査指示出力部
７３０ 検査リスト記録部
１０００ ドライブ装置
１００１ 記録媒体
１００２ 補助記憶装置
１００３ メモリ装置
１００４ ＣＰＵ
１００５ インタフェース装置
１００６ 表示装置
１００７ 入力装置
１００８ 出力装置

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】