通信装置
【課題】分散システムに属する機器間で発生した通信イベントに基づき、該通信イベントに関する情報を、一定の方法下での効率的な収集、検索に適するように生成することができる通信装置を提供すること。
【解決手段】通信制御部は、他の機器との間に発生した通信イベントに基づき、該通信イベントの相手方の装置識別子ｐを少なくとも含む、該通信イベントの属性Ｃを特定する。イベントエンコード部は、与えられた自装置識別子ｎと通信イベントの発生時刻ｔとから、与えられたセキュアハッシュ関数ｈ（）および与えられた定数ａを用いて、キー値Ｋを、式Ｋ＝ｈ（ｎ）＋ａ・ｔに従い求め、かつ、自装置識別子ｎと発生時刻ｔと通信イベントの属性Ｃとを用いて、ｎ，ｔ，Ｃの組に１対１に対応するバリュー値Ｖを求める。送信部は、キー値Ｋとバリュー値Ｖとの組を外部ストレージ装置に送出する。
【解決手段】通信制御部は、他の機器との間に発生した通信イベントに基づき、該通信イベントの相手方の装置識別子ｐを少なくとも含む、該通信イベントの属性Ｃを特定する。イベントエンコード部は、与えられた自装置識別子ｎと通信イベントの発生時刻ｔとから、与えられたセキュアハッシュ関数ｈ（）および与えられた定数ａを用いて、キー値Ｋを、式Ｋ＝ｈ（ｎ）＋ａ・ｔに従い求め、かつ、自装置識別子ｎと発生時刻ｔと通信イベントの属性Ｃとを用いて、ｎ，ｔ，Ｃの組に１対１に対応するバリュー値Ｖを求める。送信部は、キー値Ｋとバリュー値Ｖとの組を外部ストレージ装置に送出する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、他の機器との間で発生した通信イベントに基づき該通信イベントに関する情報を生成する通信装置に関する。
【背景技術】
【０００２】
個々に特定の機能を有する様々な機器がネットワークを介して分散化されそれぞれに機能する分散システムの構築ないしは利用が始まっている（スマートグリッド、分散ビル管理システムなど）。このような分散システムでは、機器どうしがネットワークを介して必要な時に必要な情報通信を行う。通常、その通信に関わった機器は、機器どうしの間で発生した通信イベントに基づいて、そのイベントに関する一定の情報を生成しログとして残す。
【０００３】
一方、このような分散システムでは、一般に、個別の機器を監視しているだけでは、システムの全体との関わりの把握が難しい。例えば、障害が発生した場合などは、障害が観測された機器から遡ってシステム中のどこを調査し、どのように対策をすればよいかというような追跡が、システムの規模の拡大に従って非常に複雑で著しく困難になる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００６−２４６０６５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
本発明は、分散システムに属する機器間で発生した通信イベントに基づき、該通信イベントに関する情報を、一定の方法下での効率的な収集、検索に適するように生成することができる通信装置を提供することを目的とする。
【課題を解決するための手段】
【０００６】
実施形態の通信装置は、通信制御部と、イベントエンコード部と、送出部とを持つ。通信制御部は、他の機器との間に発生した通信イベントに基づき、該通信イベントの相手方の装置識別子ｐを少なくとも含む、該通信イベントの属性Ｃを特定する。イベントエンコード部は、与えられた自装置識別子ｎと前記通信イベントの発生時刻ｔとから、与えられたセキュアハッシュ関数ｈ（）および与えられた定数ａを用いて、キー値Ｋを、式Ｋ＝ｈ（ｎ）＋ａ・ｔに従い求め、かつ、前記自装置識別子ｎと前記発生時刻ｔと前記通信イベントの前記属性Ｃとを用いて、ｎ，ｔ，Ｃの組に１対１に対応するバリュー値Ｖを求める。送出部は、前記キー値Ｋと前記バリュー値Ｖとの組を外部ストレージ装置に送出する。
【図面の簡単な説明】
【０００７】
【図１】実施形態の通信装置が配置、接続される関係を説明する装置関連図。
【図２】実施形態の通信装置の主要な内部構成を示すブロック図。
【図３】実施形態の通信装置が送出先とするストレージ装置（分散テーブル）におけるデータ構造を説明する概念図。
【発明を実施するための形態】
【０００８】
以上を踏まえ、以下では実施形態の通信装置を図面を参照しながら説明する。まず、図１は、実施形態の通信装置が配置、接続される関係を説明している。
【０００９】
通信装置Ｎ１、Ｎ２、Ｎ３、Ｎ４、（・・・）は、それぞれ、ネットワークを介して相互に通信できるように、このネットワークに接続されたノード装置である。例えば、ネットワークの全体としてスマートグリッドやマイクログリッドを想定する場合は、通信装置Ｎ１等は、例えば、発電機のコントローラ、太陽電池や風力発電などのパワーコンバータに搭載されたコントローラ、電気自動車やプラグインハイブリッド自動車の充電装置、ホームエネルギー管理システムの制御装置、商業ビルのエネルギー管理システムの制御装置、工業設備に関連する制御装置、電力系統監視装置、通信機能を具備する電力量計（スマートメータ）、スマートメータに対応する自動検針装置などの一部としてそれらに搭載された通信装置である。
【００１０】
これらの通信装置Ｎ１等は、それらの装置どうしがネットワーク（例えばインターネット）を介して、装置の機能に応じたプロトコルを用い必要な時に必要な情報通信を行う。通常、その通信に関わった装置は、装置どうしの間で発生した通信イベントに基づいて、そのイベントに関する一定の情報を生成しログとして残す。
【００１１】
図１では、例示として次のような通信イベントの発生を示している。すなわち、通信装置Ｎ１から同Ｎ２に、時刻ｔ１で、ある通信イベント（サブスクライブ）が発生し、通信装置Ｎ１から同Ｎ３に、時刻ｔ２で別の通信イベント（サブスクライブ）が発生し、さらに時刻ｔ５でさらに別の通信イベント（アンサブスクライブ）が発生している。また、通信装置Ｎ２から同Ｎ４に、時刻ｔ３でさらに別の通信イベント（サブスクライブ）が発生し、通信装置Ｎ３から同Ｎ４に、時刻ｔ４でさらに別の通信イベント（サブスクライブ）が発生している。
【００１２】
これにより、通信装置Ｎ１では、ログとして、「Ｎ１＠ｔ１ ｜ Ｓｄ Ｎ２」「Ｎ１＠ｔ２ ｜ Ｓｄ Ｎ３」「Ｎ１＠ｔ５ ｜ ｕＳｄ Ｎ３」が生成され保存される。通信Ｎ２、Ｎ３、Ｎ４についても、それぞれ、図１中に示すようにログが生成され保存される。ここで、ログの縦棒（｜記号）の左側は、Ｋ（後述）およびＶ（後述）の双方に関係する要素であり、右側は主にＶのみに関連する要素である。また、ログ中の“Ｓ”は、Subscribe（サブスクライブ）、“Ｓｄ”は、Subscribed（サブスクライブド：サブスクライブの受動形の略記法）であり、“ｕＳ”は、Unsubscribe（アンサブスクライブ）、“ｕＳｄ”は、Unsubscribed（アンサブスクライブド：アンサブスクライブの受動形の略記法）である。この例では、通信装置Ｎ１が情報の発信元であり、通信装置Ｎ２、Ｎ３を介して、通信装置Ｎ４に情報が流れている。この場合、通信装置Ｎ４にとって、通信装置Ｎ１が発信元であることは何ら認識されていない。
【００１３】
この実施形態は、通信イベントに関する情報を、情報の流れの、より下流になった通信装置から遡って事象の全容を容易に調査できるようにすること、特に、それに向くように通信イベントに関する情報をストレージ装置（分散テーブル）１００に記録することを目的としている。ここで、ストレージ装置１００は、ｐｕｔ（ｋｅｙ，ｖａｌｕｅ）の形式で書き込みを行い、ｇｅｔ（ｋｅｙ）→ｖａｌｕｅの形式で読み出しを行うことができるテーブルであることを想定する。分散テーブルとしては、分散ハッシュテーブルを用いることができるが、次の条件を満たす別の方式でもよい。
【００１４】
すなわち、この分散テーブルは、ｐｕｔ（ｋｅｙ，ｖａｌｕｅ）で、データエントリｖａｌｕｅをキーｋｅｙに登録することができ、このあと、データエントリｖａｌｕｅをキーｋｅｙから取得するのに、ｇｅｔ（ｋｅｙ）→ｖａｌｕｅでなすことができ、かつ、データエントリｖａｌｕｅのリスト［ｖａｌｕｅ］をキー範囲［ｋｅｙ１，ｋｅｙ２）から取得するのに、ｇｅｔＲａｎｇｅ（ｋｅｙ１，ｋｅｙ２）→［ｖａｌｕｅ］でなすことができるものであればよい。
【００１５】
図２は、実施形態の通信装置Ｎ１、Ｎ２、Ｎ３、Ｎ４、・・・（以下、代表して「通信装置Ｎ１」という）のそれぞれにおける、その主要な内部構成を示している。図２に示すように、この通信装置Ｎ１は、通信制御部１１、出力管理メモリ１２、入力管理メモリ１３、時計１４、イベントエンコーダ１５、送出部１６、分散テーブル管理部１７を有する。
【００１６】
通信制御部１１は、他の機器（通信装置）と例えばインターネットで接続されており、この装置との間に発生した通信イベントに基づき、該通信イベントの相手方の装置識別子ｐを少なくとも含む、該通信イベントの属性Ｃを特定する。属性Ｃの例として、相手方の装置識別子ｐに加え、通信イベントの情報フローの方向ｄ、通信イベントの通信識別子（セッション識別子）ｓの組を挙げることができる。属性Ｃとして、その通信イベントの発生時刻ｔを含めることにしてもよい。通信識別子ｓは、相手方との交換で相手方におけるものと同じものとして特定する。同じ相手方との複数の情報フローが発生した場合には、その都度、別の通信識別子ｓを交換、特定する。
【００１７】
情報フローの方向ｄとは、その通信イベントにおいて関係する自身と相手方との間での情報の流れの方向である。この方向ｄについては、その通信イベントにおいて、一方がサーバ、他方がクライアントであると位置づけられるとしても、実質的な情報の流れで規定し、いずれも情報の発信元になり得るとして定義される。例えば、一方が検針サーバ、他方がスマートメータ（クライアント）である場合、スマートメータによる測定値の検針サーバへの送信は、クライアントが情報発信の側である。また、スマートメータが異常状態に陥り検針サーバにその通知を行う場合も同様である。逆に、検針サーバからスマートメータに対して負荷制御コマンドを送出する場合は、検針サーバが情報発信の側である。
【００１８】
また、上記とは別の属性Ｃの例として、通信イベントの情報フローの方向ｄに代えて、次のものを用いるようにしてもよい。すなわち、ｄに代えて、この通信イベントが、通信イベントの相手方にサブスクライブして発生したもの、通信イベントの相手方からサブスクライブされて発生したもの、通信イベントの相手方にアンサブスクライブして発生したもの、および通信イベントの相手方からアンサブスクライブされて発生したものの４種のうちのいずれであるかを示す情報ｅを用いる。この場合は、通信装置Ｎ１が参加するネットワークが、いわゆるパブリッシュ-サブスクライブ（publish-subscribe）ネットワークである場合に好適に適用できる。
【００１９】
通信制御部１１は、自身が情報の発信元になった通信イベントの場合は、出力管理メモリ１２に、その属性Ｃを含むログを記録し保存する。また、通信制御部１１は、自身が情報の受け手となった通信イベントの場合は、入力管理メモリ１３に、その属性Ｃを含むログを記録し保存する。これらは、通信装置（通信装置Ｎ１等）個々における通信イベント管理のためである。出力管理メモリ１２、入力管理メモリ１３は、これらのログ情報を格納可能なメモリである。通信制御部１１は、また、特定した属性Ｃをイベントエンコーダ１５に出力する。この出力は時刻ｔの情報を含む。
【００２０】
時計１４は、発生した通信イベントの発生時刻ｔを通信制御部１１が特定するために時刻情報を提供する時計である。時刻ｔとしては、ＵＮＩＸ（登録商標）標準時間や、ある共通基準点からの経過秒数を用いることができる。
【００２１】
イベントエンコーダ１５は、与えられた自装置識別子ｎと、通信制御部１１から渡された、通信イベントの発生時刻ｔとから、与えられたセキュアハッシュ関数ｈ（）および与えられた定数ａを用いて、キー値Ｋを、式Ｋ＝ｈ（ｎ）＋ａ・ｔに従い求める。さらに、自装置識別子ｎと、通信制御部１１から渡された、発生時刻ｔと通信イベントの属性Ｃとを用いて、ｎ，ｔ，Ｃの組に１対１に対応するバリュー値Ｖを求める。
【００２２】
自装置識別子ｎとしては、例えば、ＩＰネットワークであれば、ＩＰｖ４アドレスまたはＩＰｖ６アドレスと、トランスポート層プロトコル（ＴＣＰ／ＵＤＰなど）と、ポート番号とを組み合わせたものをセキュアハッシュ関数に通して得られたものを使用できる。あるいはこれに代えて、時刻や乱数から生成したＵＵＩＤ（universally unique identifier）等を使用することもできる。これらの事情は、説明が前後するが、通信制御部１１が特定する、通信イベントの相手方の装置識別子ｐについても、相手方の装置においては同様である。
【００２３】
イベントエンコーダ１５に与えられたセキュアハッシュ関数ｈ（）としては、ＳＨＡ−１などの公知のセキュアハッシュ関数ｈ（ｋ）→｛ｘ｜ｘ∈Ｈ｝（ただしＨはハッシュ値空間）を用いることができる。定数ａは、時刻がどれだけ進めばハッシュ値であるキー値Ｋを、ハッシュ値空間Ｈ内でをどれだけ進ませるかを規定する定数である。定数ａは、換言すると、特定の通信装置（Ｎ１、・・・）がストレージ装置１００に送出する情報を、その分散テーブル内で適切に振り分けるためのパラメータとも言える。
【００２４】
定数ａについては、例えば、以下のように決めておくことができる。前提としてｔは秒数で表わす。ハッシュ値空間Ｈのビット幅ｂは、セキュアハッシュ関数ｈ（ｋ）によって定まるが、仮にｂ＝１２８ビットであるとして、１年（３１５３６０００秒）でハッシュ値空間Ｈを１周するようにバリュー値Ｖを振り分けるためには、ａは、ａ＝２１２８／３１５３６０００＝１．０８×１０３１になる。簡略的には、定数ａとして、２のべき乗の数として、この場合、ａ＝２１０３（＝１０３１．００６１）を用いるようにしてもよい。定数ａとして２のべき乗の数を用いる場合、式Ｋ＝ｈ（ｎ）＋ａ・ｔにおいて演算ａ・ｔはビットシフトになり簡単になる。
【００２５】
ｎ，ｔ，Ｃの組に１対１に対応するバリュー値Ｖを求めるには、例えば、与えられたリスト化関数ｌｉｓｔ（）を用いて、Ｖ＝ｌｉｓｔ（ｔ，ｄ，ｎ，ｐ，ｓ）で求めればよい（ｄに代えてｅを用いる場合には、Ｖ＝ｌｉｓｔ（ｔ，ｅ，ｎ，ｐ，ｓ）を用いる）。ちなみに、このようなリスト化関数ｌｉｓｔ（）を用いた場合、逆関数であるアンリスト化関数ｕｎｌｉｓｔ（）を用いれば、Ｖを引数に用いてｕｎｌｉｓｔ（Ｖ）により、ｔ，ｄ，ｎ，ｐ，ｓの組（またはｔ，ｅ，ｎ，ｐ，ｓの組）を求めることができる。
【００２６】
イベントエンコード部１５が求めたキー値Ｋおよびバリュー値Ｖは、イベントエンコード部１５から送出部１６に送られる。送出部１６は、送られてきたＫ、Ｖの組をストレージ装置１００に送出、登録する。なお、ストレージ装置１００が分散ハッシュテーブルを利用している場合であっても、このテーブルでＫに対してセキュアハッシュ化関数の適用を行うには及ばない。これは、すでにイベントエンコード部１５でｈ（ｎ）の演算がなされていて同様の効果を得ているため、および、連続した時系列の通信イベントに関する情報の検索容易化を図るためである。
【００２７】
分散テーブル管理部１７は、上記説明の動作とは直接に関係しないが、以下の機能を有している。すなわち、定期的にストレージ装置１００の状況を確認し、利用可能な分散テーブルノードを確認する。ストレージ装置１００が利用している分散テーブルが分散ハッシュテーブルで、例えばChordアルゴリズムを利用している場合であれば、ランダムな値をＫにセットした探索を行い、再帰問い合わせにより利用可能なテーブルノードを学習しておく。
【００２８】
次に図３は、実施形態の通信装置が送出先とするストレージ装置（分散テーブル）におけるデータ構造を概念的に説明している。同図において、通信イベントを表わす符号については図１と共通する。
【００２９】
分散ハッシュテーブルをはじめとする分散テーブルにおいては、データの書き込みおよびアクセスが分散していることが、効率的に動作するための必須要件である。通常は、任意のキーに対してセキュアハッシュ関数を適用することにより、任意の分布を持つキー群に対してハッシュ値の分布を一様としてアクセスを分散させることができる。
【００３０】
上記説明の実施形態においては、世界中の様々な装置が相互に通信を行う可能性があり、その場合、通信を行う装置の多様性は、通信自体の多様性に比べれば小さい。したがって、自装置識別子ｎをキーに用い、ｈ（ｎ）でハッシュ化してこれを分散ハッシュテーブルに書き込むと、特定のテーブルノードに書き込まなければならないデータ量が時間経過に従って線形に増大することになる。一方で、通信自体をキーにハッシュ化してこれを分散ハッシュテーブルに書き込むと、時系列に通信イベントが意味を有していてこれを利用（検索）しようとする場合に処理が非常に困難になってしまう。
【００３１】
そこで、上記説明の実施形態においては、装置ごとの分散性をｈ（ｎ）によって保証しつつ、近傍の時間の通信イベントに関する情報がテーブルノードの連続した領域に格納されかつ経時的に負荷分散がなされるように、キーとして、ｈ（ｎ）にａ・ｔを加えたものを使用する。
【００３２】
このようにすれば、例えば、通信装置Ｎ１、Ｎ２での通信イベントの発生については、概念的に、図３上段に示すようにテーブルに保存される。つまり、保存される場所の起点はｈ（ｎ）であり、これが通信装置ごとに決定されるので、擬似的に、通信装置ごとに分散テーブルが存在するように見える。実際は、ひとつの分散テーブルをすべての通信装置が共有している（図３下段）。ストレージ装置（分散テーブル）１００の利用については、以下で述べる適用例でさらに説明する。
【００３３】
（適用例１）
分散システムとして、スマートグリッドを考える。このスマートグリッドに、電気自動車の充電装置が接続されている。また、太陽電池に搭載のコントローラも接続されている。スマートグリッドには、これら以外にも多数の装置が接続されており、これら間で通信イベントが発生するたびに、各装置が上記説明のようにストレージ装置（分散テーブル）１００に対して、キー値Ｋ、バリュー値Ｖの組を送出、登録している。ここで、上記充電装置への給電が停止したとする。
【００３４】
給電の停止に至るステップは、ここでは例えば、次のようなものであったとする。１．地域の太陽電池による発電量の低下。２．地域全体の電力供給量が不安定化することが、地域ＥＭＳ（energy management system）により予測される。３．地域の充電装置運営会社に対する需給調整依頼。４．充電装置運営会社から充電装置への給電停止指示。
【００３５】
このとき、４番目のステップの結果のみを観測した充電装置の側からは、給電停止の原因は釈然としない。そこで、充電装置（または電気自動車）に搭載されたＥＭＳコンピュータが、充電装置の自装置識別子ｎ０を取得し、このｎ０と事象の発生時刻ｔ０とから、Ｋ＝ｈ（ｎ０）＋ａ・ｔ０を計算する。その上で、ａ・ｔ０の想定される誤差幅ｔｄを考慮して、ストレージ装置（分散テーブル）１００に対して、ｇｅｔＲａｎｇｅ（Ｋ−ｔｄ，Ｋ＋ｔｄ）を実行する。なお、誤差幅ｔｄに設定に当たっては、例えば、通信のやりとりによる遅延時間 ＋ 時計のずれから来る時刻のずれ ＋ 命令を受信してから事象が発生するまでの想定遅延時間、の計算で得た値を考慮する。
【００３６】
ストレージ装置（分散テーブル）１００への上記のような検索により、時刻ｔ０付近に存在する、充電装置に関連する通信イベントを、Ｖのリスト［Ｖ］の形で得ることができる。そして、それぞれのバリュー値Ｖを引数に用いて、例えばｕｎｌｉｓｔ（Ｖ）を実行することにより、ｔ，ｄ，ｎ，ｐ，ｓの組（またはｔ，ｅ，ｎ，ｐ，ｓの組）を求めることができる。これらの情報には、通信イベントの相手方の装置識別子ｐが含まれているので、この例の場合であれば、装置識別子ｐにより充電装置運営会社の装置を調べればよいことが分かる。
【００３７】
そこで、次に、充電装置運営会社の装置識別子ｐを新たに自装置識別子ｎ−１と設定し、停止命令の発行時刻をｔ−１として、Ｋ−１＝ｈ（ｎ−１）＋ａ・ｔ−１を計算し、ストレージ装置（分散テーブル）１００に対して、ｇｅｔＲａｎｇｅ（Ｋ−１−ｔｄ，Ｋ−１＋ｔｄ）を実行する。その後は上記説明と同様にして、地域ＥＭＳの装置に遡ることができる。
【００３８】
以後は、同様に、充電装置（または電気自動車）に搭載されたＥＭＳコンピュータがストレージ装置（分散テーブル）１００に対して検索を行うことで、事象の原因を、根源の太陽電池に搭載のコントローラまで遡ることができる。これにより、充電装置の利用者に対して、例えば、天候の回復を待つべきか、特別料金を払って別の電力を買うべきか、現在の充電で充電を一旦停止するかの選択を提示することができる。
【００３９】
（適用例２）
次に、分散システムの例として、分散ビル管理システムを考える。このようなシステムでは、各通信機器は、各ビルに設けられたセンサ、アクチュエータ、ビル情報管理システムなどにそれぞれその一部として搭載されている。
【００４０】
分散ビル管理システムでは、一般に、複数のビルの動作環境を比較検討することにより、同種の設備であっても消費電力が突然上昇するなどといった現象から故障を予知したり、利用パターンの差異から省エネルギー行動の指針を作成したりするなどといった、統合ビルマネジメントあるいはＥＳＣＯ事業のような展開が考えられる。これにより、単なるビル管理の枠を超えたシステムが構築される。
【００４１】
このような分散ビル管理システムでは、センシングされたデータがどのテナントのデータなのか、あるいは統合ビルマネジメントシステムの出力がどういったデータに基づくものなのかが見えにくくなる、という課題がある。また、これから派生して、本来データを混合してはならない（例えば契約上の理由）２つのテナントをもつビルマネジメント業者が、統合データを作成する際にどの統計値がどのテナント由来のものなのかを調べるのに手間がかかり、ヒューマンエラーが発生する余地がある、という課題もある。
【００４２】
これに対して、上記説明の通信装置を分散ビル管理システムの各機器に搭載し、さらに中間の統合データを処理する計算装置（計算ノード、計算プロセス）にも上記説明の通信装置を搭載した場合を考えると以下の利点がある。すなわち、これらの装置間で発生した通信イベントが登録されているストレージ装置１００に対して検索を行うことにより、どのデータがどの処理ルーチンを経由してどの結果に結びついているかを、容易に明らかにすることができる。
【００４３】
例えば、互いに排他的なテナントＡとテナントＢとが存在する場合、この２者の平均消費電力データと、個別の消費電力データとが明らかな場合は、互いに他方のテナントの消費電力も知ることができてしまう。これは、消費電力データから事業活動の活発さが推定できるため望ましくない。
【００４４】
そこで、統合ビルマネジメント業者は、ＥＳＣＯアプリケーションの作成に当たり、排他的なテナントＡとテナントＢ、それぞれに互いのデータを含んだ情報を与えないようにルールを設定したとする。このような場合、この業者は、データ出口の装置でストレージ装置１００を検索し、センサやプロセスに搭載の通信装置が登録した通信イベントを、時間を遡って調べることにより、誤って排他的なテナントのデータを含む集計値が出力されていないかを容易に確認できる。
【００４５】
なお、中間の統合データを処理する計算装置（計算ノード、計算プロセス）に、上記説明の通信装置を等価的に搭載するには、例えば、通信時のライブラリへの介入（dll hook等）などを用いた手法を採用することができる。また、この場合のストレージ装置１００への登録、およびストレージ装置１００に対する検索においては、公知のデータ来歴技術を適用し、より利便性を高めることができる。
【００４６】
以上説明のように、実施形態の通信装置によれば、装置間の通信イベントに関する情報を効率的に収集できるようにこの情報を生成することができる。この結果、通信イベントの因果関係を容易に調べることが可能になり、多数の通信装置に対する動的な通信イベント情報管理ができる。分散システム上の情報トレーサビリティアプリケーションの構築も容易に可能になる。
【００４７】
以上、本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これらの新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【００４８】
１１…通信制御部、１２…出力管理メモリ、１３…入力管理メモリ、１４…時計、１５…イベントエンコーダ、１６…送出部、１７…分散テーブル管理部、Ｎ１，Ｎ２，Ｎ３，Ｎ４…通信装置（ノード）、１００…ストレージ装置（分散テーブル）。
【技術分野】
【０００１】
本発明の実施形態は、他の機器との間で発生した通信イベントに基づき該通信イベントに関する情報を生成する通信装置に関する。
【背景技術】
【０００２】
個々に特定の機能を有する様々な機器がネットワークを介して分散化されそれぞれに機能する分散システムの構築ないしは利用が始まっている（スマートグリッド、分散ビル管理システムなど）。このような分散システムでは、機器どうしがネットワークを介して必要な時に必要な情報通信を行う。通常、その通信に関わった機器は、機器どうしの間で発生した通信イベントに基づいて、そのイベントに関する一定の情報を生成しログとして残す。
【０００３】
一方、このような分散システムでは、一般に、個別の機器を監視しているだけでは、システムの全体との関わりの把握が難しい。例えば、障害が発生した場合などは、障害が観測された機器から遡ってシステム中のどこを調査し、どのように対策をすればよいかというような追跡が、システムの規模の拡大に従って非常に複雑で著しく困難になる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００６−２４６０６５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
本発明は、分散システムに属する機器間で発生した通信イベントに基づき、該通信イベントに関する情報を、一定の方法下での効率的な収集、検索に適するように生成することができる通信装置を提供することを目的とする。
【課題を解決するための手段】
【０００６】
実施形態の通信装置は、通信制御部と、イベントエンコード部と、送出部とを持つ。通信制御部は、他の機器との間に発生した通信イベントに基づき、該通信イベントの相手方の装置識別子ｐを少なくとも含む、該通信イベントの属性Ｃを特定する。イベントエンコード部は、与えられた自装置識別子ｎと前記通信イベントの発生時刻ｔとから、与えられたセキュアハッシュ関数ｈ（）および与えられた定数ａを用いて、キー値Ｋを、式Ｋ＝ｈ（ｎ）＋ａ・ｔに従い求め、かつ、前記自装置識別子ｎと前記発生時刻ｔと前記通信イベントの前記属性Ｃとを用いて、ｎ，ｔ，Ｃの組に１対１に対応するバリュー値Ｖを求める。送出部は、前記キー値Ｋと前記バリュー値Ｖとの組を外部ストレージ装置に送出する。
【図面の簡単な説明】
【０００７】
【図１】実施形態の通信装置が配置、接続される関係を説明する装置関連図。
【図２】実施形態の通信装置の主要な内部構成を示すブロック図。
【図３】実施形態の通信装置が送出先とするストレージ装置（分散テーブル）におけるデータ構造を説明する概念図。
【発明を実施するための形態】
【０００８】
以上を踏まえ、以下では実施形態の通信装置を図面を参照しながら説明する。まず、図１は、実施形態の通信装置が配置、接続される関係を説明している。
【０００９】
通信装置Ｎ１、Ｎ２、Ｎ３、Ｎ４、（・・・）は、それぞれ、ネットワークを介して相互に通信できるように、このネットワークに接続されたノード装置である。例えば、ネットワークの全体としてスマートグリッドやマイクログリッドを想定する場合は、通信装置Ｎ１等は、例えば、発電機のコントローラ、太陽電池や風力発電などのパワーコンバータに搭載されたコントローラ、電気自動車やプラグインハイブリッド自動車の充電装置、ホームエネルギー管理システムの制御装置、商業ビルのエネルギー管理システムの制御装置、工業設備に関連する制御装置、電力系統監視装置、通信機能を具備する電力量計（スマートメータ）、スマートメータに対応する自動検針装置などの一部としてそれらに搭載された通信装置である。
【００１０】
これらの通信装置Ｎ１等は、それらの装置どうしがネットワーク（例えばインターネット）を介して、装置の機能に応じたプロトコルを用い必要な時に必要な情報通信を行う。通常、その通信に関わった装置は、装置どうしの間で発生した通信イベントに基づいて、そのイベントに関する一定の情報を生成しログとして残す。
【００１１】
図１では、例示として次のような通信イベントの発生を示している。すなわち、通信装置Ｎ１から同Ｎ２に、時刻ｔ１で、ある通信イベント（サブスクライブ）が発生し、通信装置Ｎ１から同Ｎ３に、時刻ｔ２で別の通信イベント（サブスクライブ）が発生し、さらに時刻ｔ５でさらに別の通信イベント（アンサブスクライブ）が発生している。また、通信装置Ｎ２から同Ｎ４に、時刻ｔ３でさらに別の通信イベント（サブスクライブ）が発生し、通信装置Ｎ３から同Ｎ４に、時刻ｔ４でさらに別の通信イベント（サブスクライブ）が発生している。
【００１２】
これにより、通信装置Ｎ１では、ログとして、「Ｎ１＠ｔ１ ｜ Ｓｄ Ｎ２」「Ｎ１＠ｔ２ ｜ Ｓｄ Ｎ３」「Ｎ１＠ｔ５ ｜ ｕＳｄ Ｎ３」が生成され保存される。通信Ｎ２、Ｎ３、Ｎ４についても、それぞれ、図１中に示すようにログが生成され保存される。ここで、ログの縦棒（｜記号）の左側は、Ｋ（後述）およびＶ（後述）の双方に関係する要素であり、右側は主にＶのみに関連する要素である。また、ログ中の“Ｓ”は、Subscribe（サブスクライブ）、“Ｓｄ”は、Subscribed（サブスクライブド：サブスクライブの受動形の略記法）であり、“ｕＳ”は、Unsubscribe（アンサブスクライブ）、“ｕＳｄ”は、Unsubscribed（アンサブスクライブド：アンサブスクライブの受動形の略記法）である。この例では、通信装置Ｎ１が情報の発信元であり、通信装置Ｎ２、Ｎ３を介して、通信装置Ｎ４に情報が流れている。この場合、通信装置Ｎ４にとって、通信装置Ｎ１が発信元であることは何ら認識されていない。
【００１３】
この実施形態は、通信イベントに関する情報を、情報の流れの、より下流になった通信装置から遡って事象の全容を容易に調査できるようにすること、特に、それに向くように通信イベントに関する情報をストレージ装置（分散テーブル）１００に記録することを目的としている。ここで、ストレージ装置１００は、ｐｕｔ（ｋｅｙ，ｖａｌｕｅ）の形式で書き込みを行い、ｇｅｔ（ｋｅｙ）→ｖａｌｕｅの形式で読み出しを行うことができるテーブルであることを想定する。分散テーブルとしては、分散ハッシュテーブルを用いることができるが、次の条件を満たす別の方式でもよい。
【００１４】
すなわち、この分散テーブルは、ｐｕｔ（ｋｅｙ，ｖａｌｕｅ）で、データエントリｖａｌｕｅをキーｋｅｙに登録することができ、このあと、データエントリｖａｌｕｅをキーｋｅｙから取得するのに、ｇｅｔ（ｋｅｙ）→ｖａｌｕｅでなすことができ、かつ、データエントリｖａｌｕｅのリスト［ｖａｌｕｅ］をキー範囲［ｋｅｙ１，ｋｅｙ２）から取得するのに、ｇｅｔＲａｎｇｅ（ｋｅｙ１，ｋｅｙ２）→［ｖａｌｕｅ］でなすことができるものであればよい。
【００１５】
図２は、実施形態の通信装置Ｎ１、Ｎ２、Ｎ３、Ｎ４、・・・（以下、代表して「通信装置Ｎ１」という）のそれぞれにおける、その主要な内部構成を示している。図２に示すように、この通信装置Ｎ１は、通信制御部１１、出力管理メモリ１２、入力管理メモリ１３、時計１４、イベントエンコーダ１５、送出部１６、分散テーブル管理部１７を有する。
【００１６】
通信制御部１１は、他の機器（通信装置）と例えばインターネットで接続されており、この装置との間に発生した通信イベントに基づき、該通信イベントの相手方の装置識別子ｐを少なくとも含む、該通信イベントの属性Ｃを特定する。属性Ｃの例として、相手方の装置識別子ｐに加え、通信イベントの情報フローの方向ｄ、通信イベントの通信識別子（セッション識別子）ｓの組を挙げることができる。属性Ｃとして、その通信イベントの発生時刻ｔを含めることにしてもよい。通信識別子ｓは、相手方との交換で相手方におけるものと同じものとして特定する。同じ相手方との複数の情報フローが発生した場合には、その都度、別の通信識別子ｓを交換、特定する。
【００１７】
情報フローの方向ｄとは、その通信イベントにおいて関係する自身と相手方との間での情報の流れの方向である。この方向ｄについては、その通信イベントにおいて、一方がサーバ、他方がクライアントであると位置づけられるとしても、実質的な情報の流れで規定し、いずれも情報の発信元になり得るとして定義される。例えば、一方が検針サーバ、他方がスマートメータ（クライアント）である場合、スマートメータによる測定値の検針サーバへの送信は、クライアントが情報発信の側である。また、スマートメータが異常状態に陥り検針サーバにその通知を行う場合も同様である。逆に、検針サーバからスマートメータに対して負荷制御コマンドを送出する場合は、検針サーバが情報発信の側である。
【００１８】
また、上記とは別の属性Ｃの例として、通信イベントの情報フローの方向ｄに代えて、次のものを用いるようにしてもよい。すなわち、ｄに代えて、この通信イベントが、通信イベントの相手方にサブスクライブして発生したもの、通信イベントの相手方からサブスクライブされて発生したもの、通信イベントの相手方にアンサブスクライブして発生したもの、および通信イベントの相手方からアンサブスクライブされて発生したものの４種のうちのいずれであるかを示す情報ｅを用いる。この場合は、通信装置Ｎ１が参加するネットワークが、いわゆるパブリッシュ-サブスクライブ（publish-subscribe）ネットワークである場合に好適に適用できる。
【００１９】
通信制御部１１は、自身が情報の発信元になった通信イベントの場合は、出力管理メモリ１２に、その属性Ｃを含むログを記録し保存する。また、通信制御部１１は、自身が情報の受け手となった通信イベントの場合は、入力管理メモリ１３に、その属性Ｃを含むログを記録し保存する。これらは、通信装置（通信装置Ｎ１等）個々における通信イベント管理のためである。出力管理メモリ１２、入力管理メモリ１３は、これらのログ情報を格納可能なメモリである。通信制御部１１は、また、特定した属性Ｃをイベントエンコーダ１５に出力する。この出力は時刻ｔの情報を含む。
【００２０】
時計１４は、発生した通信イベントの発生時刻ｔを通信制御部１１が特定するために時刻情報を提供する時計である。時刻ｔとしては、ＵＮＩＸ（登録商標）標準時間や、ある共通基準点からの経過秒数を用いることができる。
【００２１】
イベントエンコーダ１５は、与えられた自装置識別子ｎと、通信制御部１１から渡された、通信イベントの発生時刻ｔとから、与えられたセキュアハッシュ関数ｈ（）および与えられた定数ａを用いて、キー値Ｋを、式Ｋ＝ｈ（ｎ）＋ａ・ｔに従い求める。さらに、自装置識別子ｎと、通信制御部１１から渡された、発生時刻ｔと通信イベントの属性Ｃとを用いて、ｎ，ｔ，Ｃの組に１対１に対応するバリュー値Ｖを求める。
【００２２】
自装置識別子ｎとしては、例えば、ＩＰネットワークであれば、ＩＰｖ４アドレスまたはＩＰｖ６アドレスと、トランスポート層プロトコル（ＴＣＰ／ＵＤＰなど）と、ポート番号とを組み合わせたものをセキュアハッシュ関数に通して得られたものを使用できる。あるいはこれに代えて、時刻や乱数から生成したＵＵＩＤ（universally unique identifier）等を使用することもできる。これらの事情は、説明が前後するが、通信制御部１１が特定する、通信イベントの相手方の装置識別子ｐについても、相手方の装置においては同様である。
【００２３】
イベントエンコーダ１５に与えられたセキュアハッシュ関数ｈ（）としては、ＳＨＡ−１などの公知のセキュアハッシュ関数ｈ（ｋ）→｛ｘ｜ｘ∈Ｈ｝（ただしＨはハッシュ値空間）を用いることができる。定数ａは、時刻がどれだけ進めばハッシュ値であるキー値Ｋを、ハッシュ値空間Ｈ内でをどれだけ進ませるかを規定する定数である。定数ａは、換言すると、特定の通信装置（Ｎ１、・・・）がストレージ装置１００に送出する情報を、その分散テーブル内で適切に振り分けるためのパラメータとも言える。
【００２４】
定数ａについては、例えば、以下のように決めておくことができる。前提としてｔは秒数で表わす。ハッシュ値空間Ｈのビット幅ｂは、セキュアハッシュ関数ｈ（ｋ）によって定まるが、仮にｂ＝１２８ビットであるとして、１年（３１５３６０００秒）でハッシュ値空間Ｈを１周するようにバリュー値Ｖを振り分けるためには、ａは、ａ＝２１２８／３１５３６０００＝１．０８×１０３１になる。簡略的には、定数ａとして、２のべき乗の数として、この場合、ａ＝２１０３（＝１０３１．００６１）を用いるようにしてもよい。定数ａとして２のべき乗の数を用いる場合、式Ｋ＝ｈ（ｎ）＋ａ・ｔにおいて演算ａ・ｔはビットシフトになり簡単になる。
【００２５】
ｎ，ｔ，Ｃの組に１対１に対応するバリュー値Ｖを求めるには、例えば、与えられたリスト化関数ｌｉｓｔ（）を用いて、Ｖ＝ｌｉｓｔ（ｔ，ｄ，ｎ，ｐ，ｓ）で求めればよい（ｄに代えてｅを用いる場合には、Ｖ＝ｌｉｓｔ（ｔ，ｅ，ｎ，ｐ，ｓ）を用いる）。ちなみに、このようなリスト化関数ｌｉｓｔ（）を用いた場合、逆関数であるアンリスト化関数ｕｎｌｉｓｔ（）を用いれば、Ｖを引数に用いてｕｎｌｉｓｔ（Ｖ）により、ｔ，ｄ，ｎ，ｐ，ｓの組（またはｔ，ｅ，ｎ，ｐ，ｓの組）を求めることができる。
【００２６】
イベントエンコード部１５が求めたキー値Ｋおよびバリュー値Ｖは、イベントエンコード部１５から送出部１６に送られる。送出部１６は、送られてきたＫ、Ｖの組をストレージ装置１００に送出、登録する。なお、ストレージ装置１００が分散ハッシュテーブルを利用している場合であっても、このテーブルでＫに対してセキュアハッシュ化関数の適用を行うには及ばない。これは、すでにイベントエンコード部１５でｈ（ｎ）の演算がなされていて同様の効果を得ているため、および、連続した時系列の通信イベントに関する情報の検索容易化を図るためである。
【００２７】
分散テーブル管理部１７は、上記説明の動作とは直接に関係しないが、以下の機能を有している。すなわち、定期的にストレージ装置１００の状況を確認し、利用可能な分散テーブルノードを確認する。ストレージ装置１００が利用している分散テーブルが分散ハッシュテーブルで、例えばChordアルゴリズムを利用している場合であれば、ランダムな値をＫにセットした探索を行い、再帰問い合わせにより利用可能なテーブルノードを学習しておく。
【００２８】
次に図３は、実施形態の通信装置が送出先とするストレージ装置（分散テーブル）におけるデータ構造を概念的に説明している。同図において、通信イベントを表わす符号については図１と共通する。
【００２９】
分散ハッシュテーブルをはじめとする分散テーブルにおいては、データの書き込みおよびアクセスが分散していることが、効率的に動作するための必須要件である。通常は、任意のキーに対してセキュアハッシュ関数を適用することにより、任意の分布を持つキー群に対してハッシュ値の分布を一様としてアクセスを分散させることができる。
【００３０】
上記説明の実施形態においては、世界中の様々な装置が相互に通信を行う可能性があり、その場合、通信を行う装置の多様性は、通信自体の多様性に比べれば小さい。したがって、自装置識別子ｎをキーに用い、ｈ（ｎ）でハッシュ化してこれを分散ハッシュテーブルに書き込むと、特定のテーブルノードに書き込まなければならないデータ量が時間経過に従って線形に増大することになる。一方で、通信自体をキーにハッシュ化してこれを分散ハッシュテーブルに書き込むと、時系列に通信イベントが意味を有していてこれを利用（検索）しようとする場合に処理が非常に困難になってしまう。
【００３１】
そこで、上記説明の実施形態においては、装置ごとの分散性をｈ（ｎ）によって保証しつつ、近傍の時間の通信イベントに関する情報がテーブルノードの連続した領域に格納されかつ経時的に負荷分散がなされるように、キーとして、ｈ（ｎ）にａ・ｔを加えたものを使用する。
【００３２】
このようにすれば、例えば、通信装置Ｎ１、Ｎ２での通信イベントの発生については、概念的に、図３上段に示すようにテーブルに保存される。つまり、保存される場所の起点はｈ（ｎ）であり、これが通信装置ごとに決定されるので、擬似的に、通信装置ごとに分散テーブルが存在するように見える。実際は、ひとつの分散テーブルをすべての通信装置が共有している（図３下段）。ストレージ装置（分散テーブル）１００の利用については、以下で述べる適用例でさらに説明する。
【００３３】
（適用例１）
分散システムとして、スマートグリッドを考える。このスマートグリッドに、電気自動車の充電装置が接続されている。また、太陽電池に搭載のコントローラも接続されている。スマートグリッドには、これら以外にも多数の装置が接続されており、これら間で通信イベントが発生するたびに、各装置が上記説明のようにストレージ装置（分散テーブル）１００に対して、キー値Ｋ、バリュー値Ｖの組を送出、登録している。ここで、上記充電装置への給電が停止したとする。
【００３４】
給電の停止に至るステップは、ここでは例えば、次のようなものであったとする。１．地域の太陽電池による発電量の低下。２．地域全体の電力供給量が不安定化することが、地域ＥＭＳ（energy management system）により予測される。３．地域の充電装置運営会社に対する需給調整依頼。４．充電装置運営会社から充電装置への給電停止指示。
【００３５】
このとき、４番目のステップの結果のみを観測した充電装置の側からは、給電停止の原因は釈然としない。そこで、充電装置（または電気自動車）に搭載されたＥＭＳコンピュータが、充電装置の自装置識別子ｎ０を取得し、このｎ０と事象の発生時刻ｔ０とから、Ｋ＝ｈ（ｎ０）＋ａ・ｔ０を計算する。その上で、ａ・ｔ０の想定される誤差幅ｔｄを考慮して、ストレージ装置（分散テーブル）１００に対して、ｇｅｔＲａｎｇｅ（Ｋ−ｔｄ，Ｋ＋ｔｄ）を実行する。なお、誤差幅ｔｄに設定に当たっては、例えば、通信のやりとりによる遅延時間 ＋ 時計のずれから来る時刻のずれ ＋ 命令を受信してから事象が発生するまでの想定遅延時間、の計算で得た値を考慮する。
【００３６】
ストレージ装置（分散テーブル）１００への上記のような検索により、時刻ｔ０付近に存在する、充電装置に関連する通信イベントを、Ｖのリスト［Ｖ］の形で得ることができる。そして、それぞれのバリュー値Ｖを引数に用いて、例えばｕｎｌｉｓｔ（Ｖ）を実行することにより、ｔ，ｄ，ｎ，ｐ，ｓの組（またはｔ，ｅ，ｎ，ｐ，ｓの組）を求めることができる。これらの情報には、通信イベントの相手方の装置識別子ｐが含まれているので、この例の場合であれば、装置識別子ｐにより充電装置運営会社の装置を調べればよいことが分かる。
【００３７】
そこで、次に、充電装置運営会社の装置識別子ｐを新たに自装置識別子ｎ−１と設定し、停止命令の発行時刻をｔ−１として、Ｋ−１＝ｈ（ｎ−１）＋ａ・ｔ−１を計算し、ストレージ装置（分散テーブル）１００に対して、ｇｅｔＲａｎｇｅ（Ｋ−１−ｔｄ，Ｋ−１＋ｔｄ）を実行する。その後は上記説明と同様にして、地域ＥＭＳの装置に遡ることができる。
【００３８】
以後は、同様に、充電装置（または電気自動車）に搭載されたＥＭＳコンピュータがストレージ装置（分散テーブル）１００に対して検索を行うことで、事象の原因を、根源の太陽電池に搭載のコントローラまで遡ることができる。これにより、充電装置の利用者に対して、例えば、天候の回復を待つべきか、特別料金を払って別の電力を買うべきか、現在の充電で充電を一旦停止するかの選択を提示することができる。
【００３９】
（適用例２）
次に、分散システムの例として、分散ビル管理システムを考える。このようなシステムでは、各通信機器は、各ビルに設けられたセンサ、アクチュエータ、ビル情報管理システムなどにそれぞれその一部として搭載されている。
【００４０】
分散ビル管理システムでは、一般に、複数のビルの動作環境を比較検討することにより、同種の設備であっても消費電力が突然上昇するなどといった現象から故障を予知したり、利用パターンの差異から省エネルギー行動の指針を作成したりするなどといった、統合ビルマネジメントあるいはＥＳＣＯ事業のような展開が考えられる。これにより、単なるビル管理の枠を超えたシステムが構築される。
【００４１】
このような分散ビル管理システムでは、センシングされたデータがどのテナントのデータなのか、あるいは統合ビルマネジメントシステムの出力がどういったデータに基づくものなのかが見えにくくなる、という課題がある。また、これから派生して、本来データを混合してはならない（例えば契約上の理由）２つのテナントをもつビルマネジメント業者が、統合データを作成する際にどの統計値がどのテナント由来のものなのかを調べるのに手間がかかり、ヒューマンエラーが発生する余地がある、という課題もある。
【００４２】
これに対して、上記説明の通信装置を分散ビル管理システムの各機器に搭載し、さらに中間の統合データを処理する計算装置（計算ノード、計算プロセス）にも上記説明の通信装置を搭載した場合を考えると以下の利点がある。すなわち、これらの装置間で発生した通信イベントが登録されているストレージ装置１００に対して検索を行うことにより、どのデータがどの処理ルーチンを経由してどの結果に結びついているかを、容易に明らかにすることができる。
【００４３】
例えば、互いに排他的なテナントＡとテナントＢとが存在する場合、この２者の平均消費電力データと、個別の消費電力データとが明らかな場合は、互いに他方のテナントの消費電力も知ることができてしまう。これは、消費電力データから事業活動の活発さが推定できるため望ましくない。
【００４４】
そこで、統合ビルマネジメント業者は、ＥＳＣＯアプリケーションの作成に当たり、排他的なテナントＡとテナントＢ、それぞれに互いのデータを含んだ情報を与えないようにルールを設定したとする。このような場合、この業者は、データ出口の装置でストレージ装置１００を検索し、センサやプロセスに搭載の通信装置が登録した通信イベントを、時間を遡って調べることにより、誤って排他的なテナントのデータを含む集計値が出力されていないかを容易に確認できる。
【００４５】
なお、中間の統合データを処理する計算装置（計算ノード、計算プロセス）に、上記説明の通信装置を等価的に搭載するには、例えば、通信時のライブラリへの介入（dll hook等）などを用いた手法を採用することができる。また、この場合のストレージ装置１００への登録、およびストレージ装置１００に対する検索においては、公知のデータ来歴技術を適用し、より利便性を高めることができる。
【００４６】
以上説明のように、実施形態の通信装置によれば、装置間の通信イベントに関する情報を効率的に収集できるようにこの情報を生成することができる。この結果、通信イベントの因果関係を容易に調べることが可能になり、多数の通信装置に対する動的な通信イベント情報管理ができる。分散システム上の情報トレーサビリティアプリケーションの構築も容易に可能になる。
【００４７】
以上、本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これらの新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【００４８】
１１…通信制御部、１２…出力管理メモリ、１３…入力管理メモリ、１４…時計、１５…イベントエンコーダ、１６…送出部、１７…分散テーブル管理部、Ｎ１，Ｎ２，Ｎ３，Ｎ４…通信装置（ノード）、１００…ストレージ装置（分散テーブル）。
【特許請求の範囲】
【請求項１】
他の機器との間に発生した通信イベントに基づき、該通信イベントの相手方の装置識別子ｐを少なくとも含む、該通信イベントの属性Ｃを特定する通信制御部と、
与えられた自装置識別子ｎと前記通信イベントの発生時刻ｔとから、与えられたセキュアハッシュ関数ｈ（）および与えられた定数ａを用いて、キー値Ｋを、式Ｋ＝ｈ（ｎ）＋ａ・ｔに従い求め、かつ、前記自装置識別子ｎと前記発生時刻ｔと前記通信イベントの前記属性Ｃとを用いて、ｎ，ｔ，Ｃの組に１対１に対応するバリュー値Ｖを求めるイベントエンコード部と、
前記キー値Ｋと前記バリュー値Ｖとの組を外部ストレージ装置に送出する送出部と
を具備する通信装置。
【請求項２】
前記通信制御部が特定する、前記通信イベントの前記属性Ｃが、該通信イベントの相手方の前記装置識別子ｐのほかに、該通信イベントの情報フローの方向ｄと、該通信イベントの通信識別子ｓとを有し、
前記イベントエンコード部が求める前記バリュー値Ｖが、与えられたリスト化関数ｌｉｓｔ（）を用いて、Ｖ＝ｌｉｓｔ（ｔ，ｄ，ｎ，ｐ，ｓ）で求められる
請求項１記載の装置。
【請求項３】
前記通信制御部が特定する、前記通信イベントの前記属性Ｃが、該通信イベントの相手方の前記装置識別子ｐのほかに、該通信イベントが、該通信イベントの相手方にサブスクライブして発生したもの、該通信イベントの相手方からサブスクライブされて発生したもの、該通信イベントの相手方にアンサブスクライブして発生したもの、および該通信イベントの相手方からアンサブスクライブされて発生したもののうちのいずれであるかを示す情報ｅと、該通信イベントの通信識別子ｓとを有し、
前記イベントエンコード部が求める前記バリュー値Ｖが、与えられたリスト化関数ｌｉｓｔ（）を用いて、Ｖ＝ｌｉｓｔ（ｔ，ｅ，ｎ，ｐ，ｓ）で求められる
請求項１記載の装置。
【請求項４】
前記イベントエンコード部が用いる前記定数ａが、２のべき乗の数値である請求項１記載の装置。
【請求項１】
他の機器との間に発生した通信イベントに基づき、該通信イベントの相手方の装置識別子ｐを少なくとも含む、該通信イベントの属性Ｃを特定する通信制御部と、
与えられた自装置識別子ｎと前記通信イベントの発生時刻ｔとから、与えられたセキュアハッシュ関数ｈ（）および与えられた定数ａを用いて、キー値Ｋを、式Ｋ＝ｈ（ｎ）＋ａ・ｔに従い求め、かつ、前記自装置識別子ｎと前記発生時刻ｔと前記通信イベントの前記属性Ｃとを用いて、ｎ，ｔ，Ｃの組に１対１に対応するバリュー値Ｖを求めるイベントエンコード部と、
前記キー値Ｋと前記バリュー値Ｖとの組を外部ストレージ装置に送出する送出部と
を具備する通信装置。
【請求項２】
前記通信制御部が特定する、前記通信イベントの前記属性Ｃが、該通信イベントの相手方の前記装置識別子ｐのほかに、該通信イベントの情報フローの方向ｄと、該通信イベントの通信識別子ｓとを有し、
前記イベントエンコード部が求める前記バリュー値Ｖが、与えられたリスト化関数ｌｉｓｔ（）を用いて、Ｖ＝ｌｉｓｔ（ｔ，ｄ，ｎ，ｐ，ｓ）で求められる
請求項１記載の装置。
【請求項３】
前記通信制御部が特定する、前記通信イベントの前記属性Ｃが、該通信イベントの相手方の前記装置識別子ｐのほかに、該通信イベントが、該通信イベントの相手方にサブスクライブして発生したもの、該通信イベントの相手方からサブスクライブされて発生したもの、該通信イベントの相手方にアンサブスクライブして発生したもの、および該通信イベントの相手方からアンサブスクライブされて発生したもののうちのいずれであるかを示す情報ｅと、該通信イベントの通信識別子ｓとを有し、
前記イベントエンコード部が求める前記バリュー値Ｖが、与えられたリスト化関数ｌｉｓｔ（）を用いて、Ｖ＝ｌｉｓｔ（ｔ，ｅ，ｎ，ｐ，ｓ）で求められる
請求項１記載の装置。
【請求項４】
前記イベントエンコード部が用いる前記定数ａが、２のべき乗の数値である請求項１記載の装置。
【図１】
【図２】
【図３】
【図２】
【図３】
【公開番号】特開２０１２−６５１６５（Ｐ２０１２−６５１６５Ａ）
【公開日】平成２４年３月２９日（２０１２．３．２９）
【国際特許分類】
【出願番号】特願２０１０−２０８０４４（Ｐ２０１０−２０８０４４）
【出願日】平成２２年９月１６日（２０１０．９．１６）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【Ｆターム（参考）】
【公開日】平成２４年３月２９日（２０１２．３．２９）
【国際特許分類】
【出願日】平成２２年９月１６日（２０１０．９．１６）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【Ｆターム（参考）】
[ Back to top ]