特許 6937251 異常要因判定装置、制御システム、および異常要因判定方法

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

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

(11)【特許番号】6937251

(24)【登録日】2021年9月1日

(45)【発行日】2021年9月22日

(54)【発明の名称】異常要因判定装置、制御システム、および異常要因判定方法

(51)【国際特許分類】

   H04L 12/70 20130101AFI20210909BHJP

【ＦＩ】

   H04L12/70 100Z

【請求項の数】9

【全頁数】14

(21)【出願番号】特願2018-10012(P2018-10012)

(22)【出願日】2018年1月24日

(65)【公開番号】特開2019-129412(P2019-129412A)

(43)【公開日】2019年8月1日

【審査請求日】2020年3月2日

(73)【特許権者】

【識別番号】000003078

【氏名又は名称】株式会社東芝

(73)【特許権者】

【識別番号】317015294

【氏名又は名称】東芝エネルギーシステムズ株式会社

(74)【代理人】

【識別番号】100091982

【弁理士】

【氏名又は名称】永井 浩之

(74)【代理人】

【識別番号】100091487

【弁理士】

【氏名又は名称】中村 行孝

(74)【代理人】

【識別番号】100082991

【弁理士】

【氏名又は名称】佐藤 泰和

(74)【代理人】

【識別番号】100105153

【弁理士】

【氏名又は名称】朝倉 悟

(74)【代理人】

【識別番号】100107582

【弁理士】

【氏名又は名称】関根 毅

(74)【代理人】

【識別番号】100124372

【弁理士】

【氏名又は名称】山ノ井 傑

(72)【発明者】

【氏名】丸地 俊也

(72)【発明者】

【氏名】三宅 秀享

(72)【発明者】

【氏名】金井 遵

(72)【発明者】

【氏名】森 俊樹

【審査官】 大石 博見

(56)【参考文献】

【文献】 特開２０１８−００７１７９（ＪＰ，Ａ）

【文献】 特開２０１７−１９２１０５（ＪＰ，Ａ）

【文献】 特開２０１７−２１６５６９（ＪＰ，Ａ）

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

【文献】 特開２０１７−１９１９５８（ＪＰ，Ａ）

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

Ｈ０４Ｌ １２／７０

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

【請求項1】

ネットワークを介したデータ通信により機器を制御する制御装置を含む制御システム内に設けられた異常要因判定装置であって、
前記データ通信で用いられるデータに含まれる情報を取得する取得部と、
前記情報を分析し、その分析結果に基づいて前記制御システムで発生した異常の要因を、前記ネットワークを介した攻撃か、または前記機器の故障であるかを判別する分析部と、
前記分析部の判別結果を表示する表示部と、
前記データ通信を予め許可された送信元と送信先の組み合わせを登録した判定テーブルを保存する保存部と、を備え、
前記情報は、前記データの送信元および送信先を示すヘッダ情報であり、
前記分析部は、前記ヘッダ情報に示された前記送信元および前記送信先の組み合わせが前記判定テーブルに登録されているか否か判定し、前記組み合わせが前記判定テーブルに登録されていない場合には前記ヘッダ情報の前記送信元のみが前記判定テーブルの前記送信元と一致するか否か判定し、前記ヘッダ情報の前記送信元のみが前記判定テーブルの前記送信元と一致する場合には前記攻撃を前記送信元の不正操作であると判定し、そうでない場合には、前記攻撃を不正接続であると判定する、異常要因判定装置。

【請求項2】

前記判定テーブルは、前記組み合わせ毎に予め設定された前記データの伝送周期を示し、
前記分析部は、前回から今回までの前記データの取得時刻の差分時間が前記伝送周期の許容範囲外である場合、前記異常の要因を前記故障と判定する、請求項１に記載の異常要因判定装置。

【請求項3】

前記分析部は、前回の前記データの取得時刻からの経過時間が前記伝送周期に基づいて設定されたしきい値を超えた場合も、前記異常の要因を前記故障と判定する、請求項２に記載の異常要因判定装置。

【請求項4】

前記分析部の動作モードを、前記異常の要因を判別する診断モードと、前記判定テーブルを作成する学習モードとの間で切り替え可能なモード切替部を備える、請求項１から３のいずれかに記載の異常要因判定装置。

【請求項5】

前記分析部は、前記情報と、前記異常の要因の判別を補助する補助情報とを用いて前記異常の要因を判別する、請求項１に記載の異常要因判定装置。

【請求項6】

前記補助情報は、前記データまたは前記制御装置内に存在する、請求項５に記載の異常要因判定装置。

【請求項7】

前記補助情報は、前記制御装置が正常または異常であるかを自己診断した結果、前記制御装置の状態情報、および前記制御装置の動作ログの少なくとも一つを含む、請求項５または６に記載の異常要因判定装置。

【請求項8】

ネットワークを介したデータ通信により機器を制御する制御装置と、前記制御装置を前記ネットワークに接続するネットワークスイッチと、前記ネットワークスイッチに接続された異常要因判定装置と、を備える制御システムであって、
前記異常要因判定装置は、
前記データ通信で用いられるデータに含まれる情報を取得する取得部と、
前記情報を分析し、その分析結果に基づいて前記制御システムで発生した異常の要因を、前記ネットワークを介した攻撃か、または前記機器の故障であるかを判別する分析部と、
前記分析部の判別結果を表示する表示部と、
前記データ通信を予め許可された送信元と送信先の組み合わせを登録した判定テーブルを保存する保存部と、を備え、
前記情報は、前記データの送信元および送信先を示すヘッダ情報であり、
前記分析部は、前記ヘッダ情報に示された前記送信元および前記送信先の組み合わせが前記判定テーブルに登録されているか否か判定し、前記組み合わせが前記判定テーブルに登録されていない場合には前記ヘッダ情報の前記送信元のみが前記判定テーブルの前記送信元と一致するか否か判定し、前記ヘッダ情報の前記送信元のみが前記判定テーブルの前記送信元と一致する場合には前記攻撃を前記送信元の不正操作であると判定し、そうでない場合には、前記攻撃を不正接続であると判定する、制御システム。

【請求項9】

ネットワークを介したデータ通信により機器を制御する制御装置を含む制御システムの異常要因判定方法であって、
前記データ通信を予め許可された送信元と送信先の組み合わせを登録した判定テーブルを保存する保存ステップと、
前記データ通信で用いられるデータに含まれる情報を取得する取得ステップと、
前記情報を分析する分析ステップと、
分析結果に基づいて前記制御システムで発生した異常の要因を、前記ネットワークを介した攻撃か、または前記機器の故障であるかを判別するする判別ステップと、
前記判別ステップの結果を表示する表示ステップと、を備え、
前記分析ステップにおいて、ヘッダ情報に示された送信元および送信先の組み合わせが前記判定テーブルに登録されているか否か判定し、前記組み合わせが前記判定テーブルに登録されていない場合には前記ヘッダ情報の前記送信元のみが前記判定テーブルの前記送信元と一致するか否か判定し、
前記判別ステップにおいて、前記ヘッダ情報の前記送信元のみが前記判定テーブルの前記送信元と一致する場合には前記攻撃を前記送信元の不正操作であると判定し、そうでない場合には、前記攻撃を不正接続であると判定する、異常要因判定方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明の実施形態は、異常要因判定装置、制御システム、および異常要因判定方法に関する。

【背景技術】

【0002】

プラントやＦＡ（Factory Automation）等に設置された機器を制御する制御システムでは、近年、ネットワーク化が進んでいる。このような制御システムでは、ネットワークのセキュリティ対策が重要になる。
そこで、制御システム内におけるネットワークの異常を検知するＩＤＳ（Intrusion Detection System）と呼ばれる装置が知られている。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特開２０１２−１６９７３１号公報

【発明の概要】

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

【0004】

上述した制御システムで起こり得る異常は、例えば、ネットワークを介した攻撃と、機器の故障との２種類に分類できる。これらの異常に対して取るべき対策は、全く異なる。

【0005】

しかし、従来の装置は、上記２種類の異常のうち、いずれか一方のみを検知することを前提としているので、異常の要因を特定できない。そのため、制御システムで異常が発生した場合、異常への対処に多くの時間を要することが予想される。

【0006】

本発明の実施形態は、システムの異常に対して迅速に対処することが可能な異常要因判定装置、制御システム、および異常要因判定方法を提供することを目的とする。

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

【0007】

一実施形態によれば、異常要因判定装置は、ネットワークを介したデータ通信により機器を制御する制御装置を含む制御システム内に設けられている。この異常要因判定装置は、データ通信で用いられるデータに含まれる情報を取得する取得部と、その情報を分析し、その分析結果に基づいて制御システムで発生した異常の要因を、ネットワークに対する攻撃か、または機器の故障であるかを判別する分析部と、を備える。

【発明の効果】

【0008】

本実施形態によれば、制御システムの異常に対して迅速に対処することが可能となる。

【図面の簡単な説明】

【0009】

【図1】第１実施形態に係る制御システムの構成を示すブロック図である。

【図2】（ａ）は判定テーブルの一例を示す図であり、（ｂ）は判定テーブルの他の一例を示す図である。

【図3】ヘッダ情報判定処理のフローチャートである。

【図4】（ａ）は不正操作異常を通知するための表示画像の一例であり、（ｂ）は不正接続異常を通知するための表示画像の一例である。

【図5】時刻情報判定処理のフローチャートである。

【図6】（ａ）は周期異常を通知するための表示画像の一例であり、（ｂ）は出力停止異常を通知するための表示画像の一例である。

【図7】第２実施形態に係る異常要因判定装置の構成を示すブロック図である。

【図8】診断モードのフローチャートである。

【図9】第３実施形態に係る異常要因判定方法のフローチャートである。

【図10】図１０は、第４実施形態に係る異常要因判定方法のフローチャートである。

【図11】変形例に係る制御システムの構成を示すブロック図である。

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

【0010】

以下、本発明の実施形態を図面を参照して説明する。本実施形態は、本発明を限定するものではない。

【0011】

（第１実施形態）
図１は、第１実施形態に係る制御システムの構成を示すブロック図である。図１に示す制御システム１は、制御装置１０と、ＨＭＩ（Human Machine Interface）２０と、ツール３０と、ネットワークスイッチ４０と、異常要因判定装置５０と、を備える。

【0012】

制御装置１０は、ネットワークを介したデータ通信により、プラントやＦＡ等に設置された機器を制御する。制御装置１０は、例えば、図１に示すようにコントローラ１１と、センサ１２と、アクチュエータ１３と、を有する。コントローラ１１は、例えばＰＬＣ（Programmable Logic Controller）で構成されている。センサ１２は、制御対象機器の状態や環境等をセンシングする。アクチュエータ１３は、コントローラ１１の制御に基づいて動作する。本実施形態では、複数の制御装置１０が制御システム１内に設けられているが、制御装置１０の数は特に制限されない。さらに、制御装置１０の構成も、上記機器を制御する構成であればよく、図１に示す構成に限定されない。

【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】

１０ 制御装置、４０ ネットワークスイッチ、５０ 異常要因判定装置、５３ 取得部、５４ 分析部、５５ 保存部、５６ 表示部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】