JP4282635B2 - 制御ネットワークシステム及び制御ネットワークの作動方法 - Google Patents

Description

本発明は制御ネットワークシステム及び制御ネットワーク上でのデバイスの設定に関する。

近年、世界最大のコンピュータネットワークであるインターネット（Ｉｎｔｅｒｎｅｔ）の利用が促進しており、インターネット上で公開された情報やサービスを利用したり、逆に、インターネットを通してアクセスしてくる外部ユーザに対して情報やサービスを提供することが日常的に行われるようになった。インターネット利用に関する新たな技術開発がなされており、新たなコンピュータビジネスも開拓されている。

その一方で、一般的なコンピュータネットワークのみならず、建物などにおける設備管理などで利用される制御ネットワークにおいて、管理側システムのＩＰ化に伴い、エンドデバイスに対してもＩＰ化の要求が強くなってきている。しかしながら、現状ではネットワーク層を単純にＩＰ化するにとどまり、デバイス管理のためのプロトコルは旧来のままであることが多い。また、セキュリティ保護についての配慮も十分ではない。

制御機器用デバイスには、パーソナルコンピュータ（ＰＣ）のように十分なユーザインタフェース（ＵＩ）を備えていないデバイスも多く、一方で、ＩＰ化するにあたりそれぞれのデバイスのネットワーク的な設定を行う必要がある。制御ネットワーク上のノードがすべてＩＰ化されることになると、極めて多数のノードの設定を行なう必要がある。このような場合、個々のノードに対して物理的に接続し設定する方法はコスト高であるといえる。あるいは、ネットワークを利用した自動設定も考えられるが、この場合にはセキュリティが課題となる。

また、従来の制御系ネットワークにおけるデバイスの設置では、デバイスをネットワーク設計の通りに配置する必要がある場合が多く、ある固有ＩＤを持ったデバイスを必ず指定された位置に置く必要がある場合があった。これは、実際の施工などにおいての複雑さを増加させるという問題がある。

したがって、廉価で大量の制御機器のように十分なユーザインタフェースを備えないデバイスが、充分なセキュリティ保護機構を有する制御ネットワークシステムに参加できることが好ましい。また、それぞれのノードに対して事前に設定しなければならない情報はできるだけ少なくし、制御ネットワーク側から安全かつ容易にそれぞれのデバイスの設定を行なえることが好ましい。
ＲＦＣ１５１０：Ｔｈｅ Ｋｅｒｂｅｒｏｓ Ｎｅｔｗｏｒｋ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｓｅｒｖｉｃｅ （Ｖ５）． Ｊ． Ｋｏｈｌ， Ｃ． Ｎｅｕｍａｎ． Ｓｅｐｔｅｍｂｅｒ １９９３．

本発明は、設置時において安全かつ容易にノードの設定が行える制御ネットワークシステム及び制御ネットワークの作動方法を提供することを目的とする。

本発明の一観点に係る制御ネットワークシステムは、固有識別子を有するノードが接続される制御ネットワークシステムにおいて、前記ノードに対し暗号化通信のための第一の鍵を配布する第一の鍵配布手段と、前記第一の鍵を用いた暗号化通信により、前記ノードに対して前記固有識別子に対応する役割名及び第二の鍵を提供する第一の情報提供手段と、前記役割名を用いた要求に応じて、前記第二の鍵を用いた暗号化通信の際に用いられる設定情報を前記ノードに対して提供する第二の情報提供手段とを具備する制御ネットワークシステムである。

上記制御ネットワークシステムは、前記第一の情報提供手段に対し、前記第二の鍵として前記役割名に対応する通信鍵を配布する第二の鍵配布手段をさらに具備してもよい。

また上記制御ネットワークシステムは、前記第一の鍵配布手段又は前記第二の鍵配布手段に対し鍵の発行を許可又は禁止する鍵監視手段を具備してもよい。

また上記制御ネットワークシステムは、前記ノードに対し生存確認メッセージを送信し、該生存確認メッセージに対する前記ノードからの応答の有無を判定することにより、該ノードのセキュリティ上の障害を判定するノード監視手段をさらに具備してもよい。

本発明の別の観点に係る制御ネットワークシステムの作動方法は、固有識別子を有するノードが接続される制御ネットワークシステムの作動方法において、前記ノードに対し暗号化通信のための第一の鍵を配布するステップと、前記第一の鍵を用いた暗号化通信により、前記ノードに対して前記固有識別子に対応する役割名及び第二の鍵を提供するステップと、前記役割名を用いた要求に応じて、前記第二の鍵を用いた暗号化通信の際に用いられる設定情報を前記ノードに対して提供するステップとを具備する。

本発明によれば、設置時において安全かつ容易にノードの設定が行える制御ネットワークシステム及び制御ネットワークの作動方法を提供できる。

以下、図面を参照しながら本発明の実施形態を説明する。

図１は本発明の一実施形態に係る制御ネットワークの構成を示す図である。本実施形態に係る制御ネットワーク１は、ＤＨＣＰサーバ２、起動フェイズ用鍵配布センター（ＫＤＣ４Ｂ）３、鍵配布センター（ＫＤＣ）４、ランデブーサーバ（ＲＳ）５、起動フェイズ用情報供給サーバ（ＰＳ４Ｂ）６、通常設定用情報供給サーバ（ＰＳ）７、監視装置（Ｉ）８、鍵監視装置（Ｋａｕｄｉｔ）９を備える。

このような制御ネットワーク１に対し、各々がデバイスからなる複数のノード（Ｎ１，Ｎ２，...Ｎｎ）が接続される。

図２はデバイス（ノード）の構成を示すブロック図である。デバイスＮ１〜Ｎｎの各々は、固有情報記憶部１０、起動情報記憶部１１、設定情報記憶部１２を備える。また、起動フェイズ用情報提供サーバ（ＰＳ４Ｂ）６から起動情報を取得し、これを起動情報記憶部１１に対して書き込む起動情報取得部１３、通常設定用情報提供サーバ（ＰＳ）７から設定情報を取得し、これを設定情報記憶部１２に対して書き込む設定情報取得部１４を備える。また、通常のＩＰネットワークデバイスとしての機能を提供し、ＫＤＣを利用した通信処理等を担うネットワーク処理部１５を備える。

図３は鍵配布センター（ＫＤＣ）の構成を示すブロック図である。上述したように、ＫＤＣには起動フェイズ用ＫＤＣ（ＫＤＣ４Ｂ）３と通常のＫＤＣ４とがある。これらＫＤＣ３，４の各々は一般的な鍵配布センターの機能実現部として鍵配布処理部１６及び鍵監視許可取得部１７を備える。ランデブーサーバ（ＲＳ）５は例えばＤＮＳ(Domain Name Service)の技術を利用して実現される。図４は鍵監視装置の構成を示すブロック図である。鍵監視装置８は、鍵監視許可通信部１８及び鍵監視許可確認部１９を備える。図５は起動フェイズ用情報供給サーバ（ＰＳ４Ｂ）の構成を示すブロック図である。起動フェイズ用情報供給サーバ（ＰＳ４Ｂ）６は、一般的なデータベース機能を有するデータベース処理部２０、通信鍵要求部２２、通信鍵保管部２３、起動情報応答部２４を備える。

従来の制御系のネットワーク設計では、「ある固有ＩＤ（あるいはアドレス）をもったデバイスを必ず指定された位置に置く、という必要がある場合が多かった。これは、実際の施工などにおいて非常に手間を要する作業である。

例えばデバイスとして同じ形式のエアコンが１０台あるような場合を考える。これらエアコンの設置と運用の作業においては、大別すると、当該建物における制御ネットワークの設計者（以下「設計者」という）、物理的にエアコンを設置する工事を行う工事業者（以下「工事業者」という）、エアコンを製造するベンダ（以下「ベンダ」という）の三者が関係する。

従来、設計者は、ベンダがどの固有ＩＤをもつデバイス（例えばエアコン）を供給するかを知り、その固有ＩＤを元に制御ネットワークの設計を行なう。工事業者は、指定されたデバイスを指定された位置に設置する。ところが、同じ形式のエアコンが１０台あった場合、「どのエアコンをどこに置く必要があるのか？」ということを考えなければならない。

制御ネットワークの設計が存在しなければ、例えば積まれた中から適当に設置していけばよいのであるが、例えば１０階に置かなければならないエアコンを９階に配置してしまい、９階のものを１０階に配置してしまったとする。このことは建築的な設計図的には正しく施工されているが、ネットワーク的には誤っている。よって、再度施工しなおさなければならない。また、制御ネットワークの設計内容について情報を持たない人間から見た場合には、なぜ再度施工しなおさなければならないのかを理解できない。

そこで本発明の一実施形態では、図１に示した構成において、個々のデバイスＮ１〜Ｎｎに対し、互いに独立して管理が可能な固有ＩＤ（識別子）と役割名とを付与するものとする。固有ＩＤはベンダが付与する識別子であり、役割名は制御ネットワーク１の設計者が割り当てる識別子である。これら二つの識別子の関係を、物理的な施工終了後に制御ネットワーク１を使って結びつけることにより、前述の問題点を解決する。

まずベンダは、デバイス（この場合はエアコン）Ｎ１〜Ｎｎのそれぞれに対して一意の、固有ＩＤを埋め込む。固有ＩＤの具体例としては、例えば製造番号や、Ｅｔｈｅｒｎｅｔ（登録商標）のＭＡＣアドレス等が想定される。

工事業者は、制御ネットワーク１に接続される同じ形式のエアコンが１０台あった場合でも、これらを区別なく配置してよい。一方、制御ネットワーク１の設計者は、施工の事前にAirConditioner1F，AirConditioner2Fのような役割名を利用して制御ネットワーク１を設計する。制御ネットワークの設計例を図６に示す。例えば、各階床に設置されるAirConditioner1F〜AirConditioner6Fを一階に設置されるコンソールから制御する、といったように制御ネットワーク１を設計する。

デバイスＮ１〜Ｎｎには一意に定まる固有名（ＩＤ）と、起動フェイズ用の鍵（起動鍵）が埋め込まれているものとする。このようなデバイスが制御ネットワーク１に対しノードとして接続される場合、この固有ＩＤを元に制御ネットワーク１上での役割名（Ｄｎａｍｅ）と、後のすべての通信で利用する通信鍵を得る。この段階を「起動（ブート）フェイズ」（boot phase）と呼ぶ。この役割名を元に、各ノードＮ１〜Ｎｎは制御ネットワーク１上の設定情報を取得する。この段階を「初期化フェイズ」（initialize phase）と呼ぶ。セキュリティを確保するため、起動フェイズと初期化フェイズの両段階における通信にはケルベロス（Ｋｅｒｂｅｒｏｓ）による認証に基づくＩＰｓｅｃ通信（暗号化通信）が実施される。

本発明の実施形態に従えば、設計者は、設計者自身が付けた名前で制御ネットワーク１を設計することができる。施工業者は、各デバイスＮ１〜Ｎｎの固有名を考慮することなく各デバイスＮ１〜Ｎｎを設置できる。ベンダは、このデバイスがどこに出荷されるのかとを考慮することなく生産し在庫しておける。

なお、デバイスＮ１〜Ｎｎには、固有ＩＤと起動フェイズ用の鍵（起動鍵）を埋め込む必要があるが、これはデバイスが配置される制御ネットワーク１に依存することなく生成できるため、デバイスベンダは単純に値を埋め込んでいくだけでよい。

デバイス利用者（施工会社など）は、この起動鍵をベンダから入手して起動フェイズ用ＫＤＣ（ＫＤＣ４Ｂ）３に対し設定すれば良いし、あるいは比較的重要で台数の少ないデバイスであれば、ベンダのデフォルト鍵を利用せず、物理的な接触などを利用したデフォルト鍵の設定を行なっても良い。

最終的には、どの固有ＩＤがどの役割名になるか、という関係を起動フェイズ用情報提供サーバ（ＰＳ４Ｂ）６に設定する必要がある。これは、施工業者が物理的に確認し、設定するのが前提であるが、例えばデバイスが自動的に位置検出できるのであれば（例えばどのスイッチに接続されているかなど）、それを元に自動設定しても良い。

図７は本実施形態に係わるノード設定の流れを示すフローチャートである。上述したように、ノードの設定は大別すると起動フェイズＳＴ１と初期化フェイズＳＴ２の二つの段階からなる。

図８は起動フェイズにおけるノード（デバイス）の動作を示すフローチャート、図９は各ノードに予め設定された固有ＩＤと起動鍵を示す図である。図９に示されるように、ノードＮ１は固有ＩＤとしてＤＩＤ１、起動鍵としてＫｂ１を有し、ノードＮ２は固有ＩＤとしてＤＩＤ２、起動鍵としてＫｂ２を有し、ノードＮｎは固有ＩＤとしてＤＩＤｎ、起動鍵としてＫｂｎを有しているものとする。

以下、ノードＮ１を例に挙げて、当該ノードが制御ネットワーク１に設定されるまでの制御ネットワーク１の作動方法を説明する。

図８に示すように、まずステップＳＴ１０１においてノードＮ１が起動すると、ノードＮ１はＤＨＣＰサーバ２に対してＤＨＣＰ要求を送信する。これに応じてＤＨＣＰサーバ２は、起動フェイズ用ＫＤＣ（ＫＤＣ４Ｂ）３のアドレスと、該起動フェイズ用ＫＤＣ（ＫＤＣ４Ｂ）３に関する情報（例えばケルベロスのレルム(Realm)や、ランデブーサーバ５のアドレス、他に、時刻同期サーバ（図示しない）のアドレスなどをノードＮ１に対して通知する。ノードＮ１は時刻同期サーバにアクセスして自機の時刻を調整する。

次にステップＳＴ１０２において、ノードＮ１の起動情報取得部１３は、ランデブーサーバ５に対し、ノードＮ１に応対可能な起動フェイズ用情報提供サーバ（ＰＳ４Ｂ）６を問い合わせる。例えば、ランデブーサーバ５がＤＮＳを利用している場合でありかつ固有ＩＤ（ＤＩＤ）はＩＥＥＥのＥＵＩ−６４に準拠したＭＡＣアドレスであったとし、ＤＩＤ１の値が「０１２３：４５６７：８９ａｂ：ｃｄｅｆ」であったとする。固有ＩＤ（ＤＩＤ１）はノードＮ１の固有情報記憶部１０に予め設定されている。このとき、ランデブーサーバ５にはＤＩＤ１の値を検索キーとして渡す。また起動フェイズのためのドメイン名を付加する。尚、上記ＤＨＣＰの時点でこのドメイン名を提供してもよい。仮に起動フェイズ用ドメイン名が「ｂｏｏｔ．ｌｏｃａｌ」であったとすると、ＤＮＳの場合には「f.e.d.c.b.a.9.8.7.6.5.4.3.2.1.0.boot.local」が検索キーとなる。

ランデブーサーバ５は、与えられた検索キーに対応する情報提供サーバ（ＰＳ）のアドレスをノードＮ１に返す。この段階では、起動フェイズであることが検索キーから判定されるので、指定された固有ＩＤ（ＤＩＤ１）に対応する起動フェイズ用情報提供サーバ（ＰＳ４Ｂ）６のアドレスを返答する。具体的には、ランデブーサーバ（ＲＳ）５は、起動フェイズ用情報提供サーバ（ＰＳ４Ｂ）６のアドレスか、あるいはアドレスに変換可能なＩＤ、例えばＦｕｌｌｙ Ｑｕａｌｉｆｉｅｄ Ｄｏｍａｉｎ Ｎａｍｅ（ＦＱＤＮ）を返してもよい。

次にステップＳＴ１０３において、ノードＮ１は起動フェイズ用情報提供サーバ（ＰＳ４Ｂ）６との間でセキュリティ通信を行うために、起動フェイズ用ＫＤＣ（ＫＤＣ４Ｂ）３に対して鍵を要求する。このとき、ノードＮ１と起動フェイズ用ＫＤＣ（ＫＤＣ４Ｂ）３との暗号通信には、起動鍵であるＫｂ１が用いられる。ケルベロスを利用する本実施形態の場合、起動フェイズ用ＫＤＣ（ＫＤＣ４Ｂ）３との間の相互認証を経て、先ずチケットが発行され、次に通信鍵が提供される。

次にステップＳＴ１０４において、ノードＮ１の起動情報取得部１１は起動フェイズ用ＫＤＣ（ＫＤＣ４Ｂ）３から得られたチケット及び鍵を利用して起動フェイズ用情報提供サーバ（ＰＳ４Ｂ）６との相互認証を行ない、暗号化通信によって、起動情報すなわち役割名、通信鍵などの情報を要求する。このとき、起動フェイズ用情報提供サーバ（ＰＳ４Ｂ）６に対してノードＮ１は自分は「ＤＩＤ１」であると告げる。

起動フェイズ用情報提供サーバ（ＰＳ４Ｂ）６において、ノードＮ１の固有ＩＤであるＤＩＤ１が役割名Ｄｎａｍｅ１であることは事前に設定されているものとする。起動フェイズ用情報提供サーバ（ＰＳ４Ｂ）６は、起動情報の要求を受けると、通信鍵要求部２２が鍵配布センター（ＫＤＣ）４に対してＤｎａｍｅ１の通信鍵の発行を要求する。なお、鍵配布センター（ＫＤＣ）４と起動フェイズ用情報提供サーバ（ＰＳ４Ｂ）６との間は事前の信頼関係により暗号通信が可能であるものとする。

鍵配布センター（ＫＤＣ）４は通信鍵の発行要求を受けると、鍵監視許可取得部１７が鍵監視装置（Ｋａｕｄｉｔ）８に対して承認を求める。鍵監視装置（Ｋａｕｄｉｔ）８の鍵監視許可通信部１８は、この承認要求を受けると、鍵監視許可確認部１９に対して、承認要求を受けた通信鍵を発行してもよいかを確認する。ここで、発行の許可は、本実施形態のように鍵監視許可確認部１９のプログラムが既存の条件に従って自動で判断を行ってもよいし、あるいは人間が行ってもよい。通信鍵の発行が許可されたら、鍵監視許可通信部１９は、鍵配布センター（ＫＤＣ）４に対してその旨を返答する。何らかの不正な情報を検知した場合、鍵監視装置（Ｋａｕｄｉｔ）８は鍵配布センター（ＫＤＣ）４に対して鍵の発行を許可しない（禁止する）。

鍵配布センター（ＫＤＣ）４は、鍵監視装置（Ｋａｕｄｉｔ）８から通信鍵の発行許可を受けると、通信鍵Ｋｎ１を生成し、鍵配布処理部１６が起動フェイズ用情報提供サーバ（ＰＳ４Ｂ）６に対しＤｎａｍｅ１の通信鍵としてＫｎ１を通知する。同時に、鍵配布センター（ＫＤＣ）４はＤｎａｍｅ１の通信鍵としてＫｎ１を記憶する。

起動フェイズ用情報提供サーバ（ＰＳ４Ｂ）６は、鍵配布センター（ＫＤＣ）４から通信鍵Ｋｎ１を受けとると、起動情報応答部２４がノードＮ１に対し役割名Ｄｎａｍｅ１，通信鍵Ｋｎ１，必要であればその他の情報を通知する。発行された通信鍵Ｋｎ１は通信鍵保管部２３に保管される。

結果として、図１０に示すように役割名（Ｄｎａｍｅ１）と通信鍵（Ｋｎ１）からなる起動情報がノードＮ１に与えられ、当該ノードＮ１の起動情報記憶部１１に格納される。セキュリティ上の観点から可能であれば、これには不揮発な記憶手段が用いられる。

図１１は初期化フェイズにおけるノード（デバイス）の動作を示すフローチャートである。

先ずステップＳＴ２０１において、ノードＮ１の設定情報取得部１４はランデブーサーバ５に役割名Ｄｎａｍｅ１を検索キーとして告げ、この役割名Ｄｎａｍｅ１に割り当てられている情報提供サーバを問い合わせる。ランデブーサーバ５はこの問い合わせに応答し、与えられた検索キーに対応する情報提供サーバ（ＰＳ）のアドレスを返す。ここでは初期化フェイズであることが検索キーから判定され、指定された役割名Ｄｎａｍｅ１に対応する通常設定用情報提供サーバ（ＰＳ）７のアドレスが返答される。具体的には、ランデブーサーバ（ＲＳ）５は、通常設定用情報提供サーバ（ＰＳ）７のアドレスか、あるいはアドレスに変換可能なＩＤ、例えばＦｕｌｌｙ Ｑｕａｌｉｆｉｅｄ Ｄｏｍａｉｎ Ｎａｍｅ（ＦＱＤＮ）を返してもよい。

次にステップＳＴ２０２において、ノードＮ１の設定情報取得部１４は、ランデブーサーバ（ＲＳ）５から返答されたアドレスに基づき特定される通常設定用情報提供サーバ（ＰＳ）７にアクセスして設定情報を取得する。設定情報は、当該ノードが役割名に対応する役割を果たす際に、上記通信鍵Ｋｎ１を用いた暗号化通信の際に用いられる。

したがって、図１２に示すように設定情報がノードＮ１に与えられ、当該ノードＮ１の設定情報記憶部１２に格納される。セキュリティ上の観点から可能であれば、これには不揮発な記憶手段が用いられる。

以上により初期化フェイズを終了し、ノードＮ１のセットアップが完了する。

ノードＮ１と同じＫＤＣ４に属する監視装置Ｉ１は、定期的にＤｎａｍｅ１（すなわちノードＮ１）に対して生存確認のメッセージを送信しても良い。この時、監視装置Ｉ１は暗号化された通信路を利用して生存確認を行なう。もし、生存確認に応答しない場合、Ｄｎａｍｅ１の役割名を持つ機器はＫＤＣ４と通信できないなどといったセキュリティ上の障害が発生していることが分かるため、警告を出す。

尚、ノードＮ１について説明したが、他のノードＮ２，Ｎ３．．．ＮｎについてもノードＮ１と同様の動作によりセットアップされる。

以上説明した本発明の実施形態によれば、非常に多数のノードがある制御ネットワークにおいても、安全に、かつ低い設定コストでノードの設定を行なうことが可能となる。

なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。

本発明の一実施形態に係る制御ネットワークの構成を示す図 デバイス（ノード）の構成を示すブロック図 鍵配布センター（ＫＤＣ）の構成を示すブロック図 鍵監視装置の構成を示すブロック図 起動フェイズ用情報供給サーバ（ＰＳ４Ｂ）の構成を示すブロック図 制御ネットワークの設計例を示す図 本発明の一実施形態に係わるノード設定の流れを示すフローチャート 起動フェイズにおけるノード（デバイス）の動作を示すフローチャート 各ノードに予め設定された固有ＩＤと起動鍵を示す図 起動フェイズの段階でノードＮ１に格納された情報を示す図 初期化フェイズにおけるノード（デバイス）の動作を示すフローチャート 初期化フェイズの段階でノードＮ１に格納された情報を示す図

符号の説明

１…制御ネットワーク；
２…ＤＨＣＰサーバ；
３…起動フェイズ用ＫＤＣ（ＫＤＣ４Ｂ）；
４…鍵配布センター（ＫＤＣ）；
５…ランデブーサーバ（ＲＳ）；
６…起動フェイズ用情報提供サーバ（ＰＳ４Ｂ）；
７…通常設定用情報提供サーバ（ＰＳ）；
８…監視装置（Ｉ）；
９…鍵監視装置（Ｋａｕｄｉｔ）；
Ｎ１〜Ｎｎ…ノード（デバイス）

Claims (5)

1. 固有識別子を有するノードが接続される制御ネットワークシステムにおいて、
   前記ノードに対し暗号化通信のための第一の鍵を配布する第一の鍵配布手段と、
   前記第一の鍵を用いた暗号化通信により、前記ノードに対して前記固有識別子に対応する役割名及び第二の鍵を提供する第一の情報提供手段と、
   前記役割名を用いた要求に応じて、前記第二の鍵を用いた暗号化通信の際に用いられる設定情報を前記ノードに対して提供する第二の情報提供手段とを具備する制御ネットワークシステム。
2. 前記第一の情報提供手段に対し、前記第二の鍵として前記役割名に対応する通信鍵を配布する第二の鍵配布手段を具備する請求項１に記載の制御ネットワークシステム。
3. 前記第一の鍵配布手段又は前記第二の鍵配布手段に対し鍵の発行を許可又は禁止する鍵監視手段を具備する請求項１又は２に記載の制御ネットワークシステム。
4. 前記ノードに対し生存確認メッセージを送信し、該生存確認メッセージに対する前記ノードからの応答の有無を判定することにより、該ノードのセキュリティ上の障害を判定するノード監視手段を具備する請求項１乃至３のいずれかに記載の制御ネットワークシステム。
5. 固有識別子を有するノードが接続される制御ネットワークシステムの作動方法において、
   前記ノードに対し暗号化通信のための第一の鍵を鍵配布手段が配布するステップと、
   前記第一の鍵を用いた暗号化通信により、前記ノードに対して前記固有識別子に対応する役割名及び第二の鍵を第一の情報提供手段が提供するステップと、
   前記役割名を用いた要求に応じて、前記第二の鍵を用いた暗号化通信の際に用いられる設定情報を前記ノードに対して第二の情報提供手段が提供するステップとを具備する制御ネットワークシステムの作動方法。

Images