(57)【要約】【課題】システムの異常に対して的確に対処することが可能な異常要因判定装置を提供する。【解決手段】一実施形態によれば、異常要因判定装置は、ネットワークを介したデータ通信により機器を制御する制御装置を含む制御システム内に設けられている。この異常要因判定装置は、データ通信で用いられるデータを取得する取得部と、データの送受信に関する情報を登録した第１判定テーブルを保存する判定テーブル保存部と、制御システムで過去に発生した異常の要因を示す異常ログを保存する異常ログ保存部と、第１判定テーブルと異常ログとを用いて、取得部で取得されたデータを分析し、その分析結果に基づいて異常の要因を、ネットワークを介した攻撃か、または機器の故障であるかを判別する分析部と、を備える。【選択図】図１
2020061717.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介したデータ通信により機器を制御する制御装置を含む制御システム内に設けられた異常要因判定装置であって、
前記データ通信で用いられるデータを取得する取得部と、
前記データの送受信に関する情報を登録した第１判定テーブルを保存する判定テーブル保存部と、
前記制御システムで過去に発生した異常の要因を示す異常ログを保存する異常ログ保存部と、
前記第１判定テーブルと前記異常ログとを用いて、前記取得部で取得された前記データを分析し、その分析結果に基づいて前記異常の要因を、前記ネットワークを介した攻撃か、または前記機器の故障であるかを判別する分析部と、
を備える異常要因判定装置。
【請求項２】
前記第１判定テーブルには、前記データ通信を予め許可された前記データの送信元および送信先を示すヘッダ情報が前記情報として登録され、
前記分析部は、前記取得部で取得された前記データに前記ヘッダ情報が含まれておらず、かつ、前記異常ログ保存部に、前記異常ログが全く存在しないかまたは攻撃の異常ログが保存されている場合、前記異常の要因を前記ネットワークを介した攻撃であると判定するとともに、判定結果を前記異常ログ保存部に保存する、請求項１に記載の異常要因判定装置。
【請求項３】
前記分析部は、前記取得部で取得された前記データに前記ヘッダ情報が含まれておらず、かつ、前記異常ログ保存部に故障の異常ログが保存されている場合、前記異常の要因を前記機器の故障であると判定するとともに、判定結果を前記異常ログ保存部に保存する、請求項２に記載の異常要因判定装置。
【請求項４】
前記判定テーブル保存部は、前記制御装置を制御する制御値の許容範囲を示す第２判定テーブルも保存し、
前記分析部は、前記取得部で取得された前記データに含まれた前記制御値が前記許容範囲外であり、かつ、前記異常ログ保存部に、前記異常ログが全く存在しないかまたは故障の異常ログが保存されている場合、前記異常の要因を前記機器の故障であると判定するとともに、判定結果を前記異常ログ保存部に保存する、請求項１に記載の異常要因判定装置。
【請求項５】
前記分析部は、前記取得部で取得された前記データに含まれた前記制御値が前記許容範囲外であり、かつ、前記異常ログ保存部に異常の異常ログが保存されている場合、前記異常の要因を前記ネットワークを介した攻撃であると判定するとともに、判定結果を前記異常ログ保存部に保存する、請求項４に記載の異常要因判定装置。
【請求項６】
前記分析部の動作モードを、前記異常の要因を判別する診断モードと、前記第１判定テーブルおよび前記第２判定テーブルを作成する学習モードとの間で切り替え可能なモード切替部を備える、請求項４または５に記載の異常要因判定装置。
【請求項７】
前記モード切替部が前記分析部の動作モードを前記学習モードに切り替えた場合、前記分析部は、前記取得部で取得した前記データの送信元、送信先、周期、取得時刻を前記第１判定テーブルに登録し、前記データの前記制御値に応じて前記許容範囲を更新する、、請求項６に記載の異常要因判定装置。
【請求項８】
ネットワークを介したデータ通信により機器を制御する制御装置と、前記制御装置を前記ネットワークに接続するネットワークスイッチと、前記ネットワークスイッチに接続された異常要因判定装置と、を備える制御システムであって、
前記異常要因判定装置は、
前記データ通信で用いられるデータを取得する取得部と、
前記データの送受信に関する情報を登録した第１判定テーブルを保存する判定テーブル保存部と、
前記制御システムで過去に発生した異常の要因を示す異常ログを保存する異常ログ保存部と、
前記第１判定テーブルと前記異常ログとを用いて、前記取得部で取得された前記データを分析し、その分析結果に基づいて前記異常の要因を、前記ネットワークを介した攻撃か、または前記機器の故障であるかを判別する分析部と、
を備える異常要因判定装置。
【請求項９】
ネットワークを介したデータ通信により機器を制御する制御装置を含む制御システムの異常要因判定方法であって、
前記データ通信で用いられるデータを取得し、
前記データの送受信に関する情報を登録した第１判定テーブルと、前記制御システムで過去に発生した異常の要因を示す異常ログとを用いて、取得したデータを分析し、
分析結果に基づいて前記異常の要因を、前記ネットワークを介した攻撃か、または前記機器の故障であるかを判別する、
異常要因判定方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、異常要因判定装置、制御システム、および異常要因判定方法に関する。
【背景技術】
【０００２】
プラントやＦＡ（Factory Automation）等に設置された機器を制御する制御システムでは、近年、ネットワーク化が進んでいる。このような制御システムでは、ネットワークのセキュリティ対策が重要になる。
【０００３】
そこで、制御システム内におけるネットワークの異常を検知するＩＤＳ（Intrusion Detection System）と呼ばれる装置が知られている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１２−１６９７３１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
上述した制御システムで起こり得る異常は、例えば、ネットワークを介した攻撃と、機器の故障との２種類に分類できる。これらの異常に対して取るべき対策は、全く異なる。
【０００６】
しかし、従来の装置は、上記２種類の異常のうち、いずれか一方のみを検知することを前提としているので、異常の要因を特定できない。そのため、制御システムで異常が発生した場合、異常への対処が不十分であることが予想される。
【０００７】
本発明の実施形態は、システムの異常に対して的確に対処することが可能な異常要因判定装置、制御システム、および異常要因判定方法を提供することを目的とする。
【課題を解決するための手段】
【０００８】
一実施形態によれば、異常要因判定装置は、ネットワークを介したデータ通信により機器を制御する制御装置を含む制御システム内に設けられている。この異常要因判定装置は、データ通信で用いられるデータを取得する取得部と、データの送受信に関する情報を登録した第１判定テーブルを保存する判定テーブル保存部と、制御システムで過去に発生した異常の要因を示す異常ログを保存する異常ログ保存部と、第１判定テーブルと異常ログとを用いて、取得部で取得されたデータを分析し、その分析結果に基づいて異常の要因を、ネットワークを介した攻撃か、または機器の故障であるかを判別する分析部と、を備える。
【発明の効果】
【０００９】
本実施形態によれば、制御システムの異常に対して的確に対処することが可能となる。
【図面の簡単な説明】
【００１０】
【図１】第１実施形態に係る制御システムの構成を示すブロック図である。
【図２】（ａ）は第１判定テーブルの一例を示し、（ｂ）は第２判定テーブルの一例を示す図である。
【図３】異常ログテーブルの一例を示す図である。
【図４】異常要因判定処理のフローチャートである。
【図５】ヘッダ情報判定処理のフローチャートである。
【図６】異常ログ確認処理のフローチャートである。
【図７】時刻情報判定処理のフローチャートである。
【図８】ペイロード処理のフローチャートである。
【図９】第２実施形態に係る異常要因判定装置の構成を示すブロック図である。
【図１０】第２実施形態に係る異常要因判定装置の全体的な処理内容を示すフローチャートである。
【図１１】判定テーブル作成処理のフローチャートである。
【図１２】第３実施形態に係る異常要因判定装置の構成を示すブロック図である。
【発明を実施するための形態】
【００１１】
以下、本発明の実施形態を図面を参照して説明する。本実施形態は、本発明を限定するものではない。
【００１２】
（第１実施形態）
図１は、第１実施形態に係る制御システムの構成を示すブロック図である。図１に示す制御システム１は、制御装置１０と、ＨＭＩ（Human Machine Interface）２０と、ツール３０と、ネットワークスイッチ４０と、異常要因判定装置５０と、を備える。
【００１３】
制御装置１０は、ネットワークを介したデータ通信により、プラントやＦＡ等に設置された機器を制御する。本実施形態では、複数の制御装置１０が制御システム１内に設けられているが、制御装置１０の数は特に制限されない。また、制御装置１０の構成も、上記機器を制御できる構成であれば特に限定されない。
【００１４】
ＨＭＩ２０は、ネットワークスイッチ４０を介して各制御装置１０の状態を監視する。ツール３０は、ネットワークスイッチ４０を介して各制御装置１０の制御プログラムを変更するエンジニアリングツールである。
【００１５】
ネットワークスイッチ４０は、各制御装置１０をネットワークに接続する。本実施形態では、このネットワークは、Ｅｔｈｅｒｎｅｔ（登録商標）であるが、他の規格のネットワークであってもよい。また、ネットワークスイッチ４０はミラーポートを有し、このミラーポートに異常要因判定装置５０が接続される。これにより、異常要因判定装置５０は、ネットワークスイッチ４０を介して、制御システム１内を伝送するパケット形式の全てのデータを取得できる。ただし、データ取得方法は、上記ミラーポートに制限されない。例えば、制御システム１内でブロードキャストやマルチキャスト伝送を用いて、異常要因判定装置５０が取得可能な方法などを用いてもよい。
【００１６】
異常要因判定装置５０は、通信インタフェース部５１と、タイマ部５２と、取得部５３と、分析部５４と、判定テーブル保存部５５と、異常ログ保存部５６と、表示部５７と、を有する。異常要因判定装置５０を構成するこれらの構成要素は、ハードウェアで実現されてもよいし、ソフトウェアで実現されてもよい。また、判定テーブル保存部５５および異常ログ保存部５６は、一体化されていてもよい。
【００１７】
通信インタフェース部５１は、ネットワークスイッチ４０を介してデータを入出力する。タイマ部５２は現在時刻を取得する。取得部５３は、通信インタフェース部５１で受信したデータを取得する。また、取得部５３は、タイマ部５２から取得した時刻情報を取得データに付与して分析部５４へ出力する。
【００１８】
分析部５４は、判定テーブル保存部５５と異常ログ保存部５６とにそれぞれ保存されているテーブルを用いて、取得部５３で取得されたデータを分析する。また、分析部５４は、その分析結果に基づいて異常の要因を判別する。
【００１９】
判定テーブル保存部５５は、分析部５４の分析で用いられる２つの判定テーブルを保存する。ここで、図２（ａ）および図２（ｂ）を参照して判定テーブル保存部５５に保存される判定テーブルについて説明する。
【００２０】
図２（ａ）に示す第１判定テーブル１０１は、後述するヘッダ情報判定処理で用いられる。第１判定テーブル１０１には、予めデータ通信が許可された送信元と送信先の組み合わせと、その組み合わせ毎に予め設定されたデータの伝送周期と、前回のデータ取得時刻と、が示されている。本実施形態では、ＩＰアドレスが送信元および送信先の識別情報として用いられている。また、データ取得時刻は、データ取得のたびに更新される。第１判定テーブル１０１の項目は、図２（ａ）に示す項目に制限されず、例えばプロトコル情報も含んでいてよい。この場合、セキュリティの判定をより厳密にすることができる。
【００２１】
図２（ｂ）に示す第２判定テーブル１０２は、後述するペイロード判定処理で用いられる。取得部５３で取得されるデータには、制御装置１０の制御値として用いる第１フィールド部分と、伝送の健全性を確認するため、タイムスタンプのように通信パケットごとにインクリメントされる第２フィールド部分がある。そのため、第２判定テーブル１０２では、フィールドごとにフラグ(以下、ＦＬＧ)が設定されている。本実施形態では、ＦＬＧ「０」が第１フィールド部分に対応し、ＦＬＧ「１」が第２フィールド部分に対応する。
【００２２】
また、第１フィールド部分、すなわち制御値には、最小値と最大値とが登録されている。一方、第２フィールド部分、すなわち健全性確認データには、前回値が登録されている。前回値は、健全性確認データの取得毎に更新される。
【００２３】
異常ログ保存部５６は、分析部５４の分析で用いられる異常ログテーブルを保存する。ここで、図３を参照して異常ログ保存部５６に保存される異常ログテーブルについて説明する。
【００２４】
図３に示す異常ログテーブル１０３は、制御システム１で過去に発生した異常の発生時刻、種別、および内容を示す。なお、図３には、異常種別が「故障」しか記載されていないが、異常の要因がネットワークを介した攻撃である場合には、「攻撃」と記載される。
【００２５】
以下、図４を参照して、上述した異常要因判定装置５０による異常要因判定方法について説明する。図４は、異常要因判定処理のフローチャートである。異常要因判定装置５０では、通信インタフェース部５１が、ネットワークスイッチ４０を介して新たにデータを受信すると（ステップＳ１００）、ヘッダ情報処理（ステップＳ２００）、時刻情報判定処理（ステップＳ３００）、およびペイロード処理（ステップＳ４００）がこの順に行われる。以下、各処理について詳しく説明する。
【００２６】
図５は、ヘッダ情報判定処理のフローチャートである。まず、取得部５３が、通信インタフェース部５１で受信されたデータからヘッダ情報を取得する（ステップＳ２０１）。このとき、取得部５３は、タイマ部５２から時刻情報を取得して、取得したヘッダ情報とともに分析部５４へ出力する。
【００２７】
分析部５４は、ヘッダ情報に示された送信元ＩＰアドレスおよび送信先ＩＰアドレスの組み合わせが、判定テーブル保存部５５の第１判定テーブル１０１に登録されているか否かを判定する（ステップＳ２０２）。上記組み合わせが登録されている場合、分析部５４は、正常であると判定する（ステップＳ２０３）。この場合、処理が終了する。反対に、上記組み合わせが第１判定テーブル１０１に登録されていない場合、分析部５４は、異常ログ確認処理を行う（ステップＳ２０４）
【００２８】
図６は、異常ログ確認処理のフローチャートである。異常ログ確認処理では、まず、分析部５４は、異常要因が故障である異常ログが異常ログ保存部５６の異常ログテーブル１０３に保存されているか否かを確認する（ステップＳ２１１）。故障の異常ログが保存されている場合、分析部５４は、今回取得した異常データの時刻や内容を異常ログテーブル１０３に新たに保存する（ステップＳ２１２）。また、分析部５４は、異常要因を機器の故障であると判定する（ステップＳ２１３）。そのため、異常ログテーブル１０３の異常種別は、「故障」と登録される。
【００２９】
故障の異常ログが異常ログテーブル１０３に保存されていない場合、分析部５４は、異常要因が攻撃である異常ログが異常ログテーブル１０３に保存されているか否かを確認する（ステップＳ２１４）。攻撃の異常ログも保存されていない場合、分析部５４は、今回取得した異常データの時刻や内容を異常ログテーブル１０３に新たに保存する（ステップＳ２１５）。また、分析部５４は、異常要因をネットワークを介した攻撃であると判定する（ステップＳ２１６）。そのため、異常ログテーブル１０３の異常種別は、「攻撃」と登録される。
【００３０】
攻撃の異常ログが保存されている場合も、分析部５４は、今回取得した異常データの時刻や内容を異常ログテーブル１０３に新たに保存する（ステップＳ２１７）。また、分析部５４は、異常要因をネットワークを介した攻撃であると判定する（ステップＳ２１８）。
【００３１】
上述した異常ログ確認処理では、過去に異常ログが全くない、または攻撃の異常ログが異常ログテーブル１０３に保存されている場合、分析部５４は、今回の異常の要因も攻撃である可能性が高いと判定し、表示部５７がその旨を表示する。一方、故障の異常ログが異常ログテーブル１０３に保存されている場合、故障により送信先や伝送元のＩＰアドレスが変化してしまった可能性があるので、分析部５４は、今回の異常の要因も故障である可能性が高いと判定し、表示部５７がその旨を表示する。なお、攻撃の異常ログおよび故障の異常ログの両方が、異常ログテーブル１０３に保存されている場合には、分析部５４は、例えば両者の頻度に基づいて、異常の要因を判定する。
【００３２】
異常ログ確認処理が終了すると、次に、時刻情報判定処理を行う。図７は、時刻情報判定処理のフローチャートである。
【００３３】
図７に示すフローチャートは、２種類の処理フローに分類される。一方の処理フローは、新規のパケットデータを受信した際に周期の異常を分析する周期異常分析フローである。他方の処理フローは、新規のパケットデータを受信するまでの間に出力を停止してしまった機器を分析する出力停止分析フローである。
【００３４】
周期異常分析フローでは、通信インタフェース部５１がデータを受信すると（ステップＳ３０１）、分析部５４は、上述したヘッダ情報判定処理で取得部５３から入力されたヘッダ情報および時刻情報に基づいて差分時間Δｔ１を算出する（ステップＳ３０２）。差分時間Δｔ１は、時刻情報に示された現在時刻と、判定テーブルに記録された前回のデータ取得時刻の差に相当する。すなわち、差分時間Δｔ１は、前回から今回までのデータの取得時刻の差分時間に相当する。
【００３５】
続いて、分析部５４は、算出した差分時間Δｔ１が伝送周期の許容範囲内であるか否かを判定する（ステップＳ３０３）。例えば伝送周期２ｍｓの許容範囲が±１０％に設定されている場合、差分時間Δｔ１が１．８ｍｓ〜２．２ｍｓの範囲内であれば、分析部５４は、正常と判定する。この場合、分析部５４は、第１判定テーブル１０１の前回取得時刻を今回の取得時刻に更新する（ステップＳ３０４）。
【００３６】
一方、差分時間Δｔ１が許容範囲外である場合、分析部５４は、伝送周期異常と判定し、異常ログ確認処理を行う（ステップＳ３０５）。ステップＳ３０５の異常ログ確認処理では、異常ログテーブル１０３において、異常ログが何も登録されていない、または故障の異常ログが登録されている場合には、分析部５４は、異常の要因を故障と判定する。一方、攻撃の異常ログが異常ログテーブル１０３に登録されている場合には、分析部５４は、異常の要因を攻撃と判定する。その後、表示部５７が判定結果に応じて故障または攻撃の可能性がある旨を表示するとともに、伝送周期異常であることも表示する（ステップＳ３０６）。これで、周期異常分析フローは終了する。
【００３７】
周期異常分析フローが終了してから通信インタフェース部５１が次の新規のパケットデータを受信するまでの間に、出力停止分析処理を行う。出力停止分析フローでは、分析部５４は、経過時間Δｔ２を算出する（ステップＳ３０７）。経過時間Δｔ２は、タイマ部５２の時刻情報に示された現在時刻と判定テーブルに記録された前回のデータ取得時刻の差に相当する。すなわち、経過時間Δｔ２は、前回のデータ取得時刻からの経過時間に相当する。
【００３８】
続いて、分析部５４は、算出した経過時間Δｔ２が周期に基づいて設定されたしきい値を超えているか否かを判定する（ステップＳ３０８）。しきい値は、例えば伝送周期の２倍に設定される。例えば、伝送周期が２ｍｓの場合、経過時間Δｔ２が４ｍｓを超えていなければ、分析部５４は、正常であると判定する（ステップＳ３０９）。一方、経過時間Δｔ２が４ｍｓを超えている、すなわち前回のデータ受信時から４ｍｓ以上次のデータを受信していない場合、分析部５４は、機器の出力が停止したと判断し、異常ログデータ確認処理を行う（ステップＳ３１０）。
【００３９】
ステップＳ３１０の異常ログ確認処理では、異常ログテーブル１０３において、異常ログが何も登録されていない、または故障の異常ログが登録されている場合には、分析部５４は、異常の要因を故障と判定する。一方、攻撃の異常ログが異常ログテーブル１０３に登録されている場合には、分析部５４は、異常の要因を攻撃と判定する。その後、表示部５７が判定結果に応じて故障または攻撃の可能性がある旨を表示するとともに、出力停止異常であることも表示する（ステップＳ３１１）。これで、出力停止分析フローは終了する。
【００４０】
上記のように時刻情報判定処理が終了すると、最後にペイロード判定処理を行う。図８は、ペイロード処理のフローチャートである。
【００４１】
図８に示すフローチャートでは、まず、分析部５４は、取得部５３の取得データに示されたＦＬＧが「０」であるか否かを確認する（ステップＳ４０１）。ＦＬＧが「０」である場合、分析部５４は、第１フィールド値、すなわち取得データの第１フィールド部分に示された制御値を取得する（ステップＳ４０２）。続いて、分析部５４は、取得した制御値が許容範囲内であるか否かを判定する（ステップＳ４０３）。ステップＳ４０３では、分析部５４は、取得した制御値が、判定テーブル保存部５５の第２判定テーブル１０２において、当該制御値と対応するフィールド番号の最小値と最大値で規定される許容範囲内であるか否かを確認する。取得した制御値が、上記許容範囲内に収まっている場合、分析部５４は、正常であると判定し、ペイロード処理は終了する。一方、取得した制御値が、上記許容範囲外である場合、異常ログ確認処理を行う（ステップＳ４０４）。
【００４２】
ステップＳ４０４の異常ログ確認処理では、異常ログテーブル１０３において、異常ログが何も登録されていない、または故障の異常ログが登録されている場合には、分析部５４は、異常の要因を故障と判定する。一方、攻撃の異常ログが異常ログテーブル１０３に登録されている場合には、分析部５４は、異常の要因を攻撃と判定する。この場合、セキュリティ攻撃により制御値が意図的に変化した可能性が高いため、表示部５７は、その旨を表示する（ステップＳ４０５）。
【００４３】
ステップＳ４０１において、ＦＬＧが「０」でない、つまり「１」である場合、分析部５４は、第２フィールド値、すなわち取得データの第２フィールド部分に示された健全性確認データを取得する（ステップＳ４０５）。分析部５４は、取得した健全性確認データが、第２判定テーブル１０２の前回値から更新された値であるか否かを確認する（ステップＳ４０６）。
【００４４】
取得した健全性確認データが更新されている場合、分析部５４は、正常であると判定し、ペイロード処理は終了する。一方、取得した健全性確認データが更新されていない場合、異常ログ確認処理を行う（ステップＳ４０７）。ステップＳ４０７の異常ログ確認処理は、上述したステップＳ４０４の異常ログ確認処理と同様であるため、説明を省略する。その後、表示部５７が判定結果に応じて故障または攻撃の可能性がある旨を表示する（ステップＳ４０８）。
【００４５】
以上説明した本実施形態によれば、制御システム１内で異常が発生した場合、分析部５４が、その異常の要因を、ネットワークを介した攻撃か、または機器の故障であるかを判別する。これにより、制御システム１の異常に対して的確に対処することができる。
【００４６】
さらに、本実施形態では、分析部５４は、異常ログ保存部５６に保存された異常ログテーブル１０３を用いて判別している。このように、分析部５４が今回取得したデータだけでなく、過去の異常ログも用いて異常要因を特定することによって、故障にみせかけた攻撃や、攻撃に近い挙動をする故障といった要因判定が困難な異常にも的確に対処することができる。
【００４７】
（第２実施形態）
以下、第２実施形態について、第１実施形態と異なる点を中心に説明する。本実施形態に係る制御システムでは、異常要因判定装置の構成が第１実施形態と異なる。図９は、第２実施形態に係る異常要因判定装置の構成を示すブロック図である。上述した第１実施形態と同様の構成要素には同じ符号を付し、詳細な説明を省略する。
【００４８】
図９に示す異常要因判定装置５０ａは、モード切替部５８を有する点で第１実施形態と異なる。なお、本実施形態においても、異常要因判定装置５０ａは、ハードウェアで実現されてもよいし、ソフトウェアで実現されてもよい。
【００４９】
モード切替部５８は、分析部５４の動作モードを、異常の要因を判別する診断モードと、第１判定テーブル１０１および第２判定テーブル１０２を作成する学習モードとの間で切り替える。モード切替部５８は、予め設定された時間帯に応じて分析部５４の動作モードを切り替えてもよいし、ユーザの操作を受け付けたときに切り替えてもよい。
【００５０】
図１０は、本実施形態に係る異常要因判定装置５０ａの全体的な処理内容を示すフローチャートである。この異常要因判定装置５０ａでは、通信インタフェース部５１が、ネットワークスイッチ４０を介して新たにデータを受信すると（ステップＳ５０１）、モード切替部５８の状態に応じて、分析部５４の動作モードが診断モードであるか否かを確認する（ステップＳ５０２）。
【００５１】
分析部５４が診断モードである場合、ヘッダ情報処理（ステップＳ５０３）、時刻情報判定処理（ステップＳ５０４）、およびペイロード処理（Ｓ５０５）がこの順で行われる。これらの処理フローは、第１実施形態で説明したステップＳ２００のヘッダ情報処理、ステップＳ３００の時刻情報判定処理、およびステップＳ４００のペイロード処理と同様であるので説明を省略する。
【００５２】
一方、分析部５４が診断モードでない、つまり学習モードである場合、判定テーブル作成処理（ステップＳ５０６）が行われる。ここで、図１１を参照して判定テーブル作成処理を説明する。
【００５３】
図１１は、判定テーブル作成処理のフローチャートである。まず、取得部５３が、通信インタフェース部５１の受信データからヘッダ情報を取得する（ステップＳ６０１）。続いて、取得部５３は、タイマ部５２から時刻情報を取得して、ヘッダ情報とともに分析部５４へ出力する（ステップＳ６０２）。
【００５４】
分析部５４は、ヘッダ情報に示された送信元ＩＰアドレスおよび送信先ＩＰアドレスがが判定テーブル保存部５５に保存された第１判定テーブル１０１に既に登録されているか否かを判定する（ステップＳ６０３）。送信元ＩＰアドレスおよび送信先ＩＰアドレスが登録されている場合、分析部５４は、データ伝送の周期を算出して第１判定テーブル１０１に登録する（ステップＳ６０４）。ステップＳ６０４では、分析部５４は、時刻情報に示された現在時刻と第１判定テーブル１０１に記録された前回取得時刻との差分時間を周期として算出する。
【００５５】
続いて、分析部５４は、受信データから第１フィールド部分の制御値を取得する。このとき、取得した制御値に応じて最小値と最大値をそれぞれ変更する場合には、分析部５４は、第２判定テーブル１０２に変更後の最小値と最大値を登録する。これにより、第２判定テーブル１０２が更新される（ステップＳ６０５）。
【００５６】
一方、送信元ＩＰアドレスおよび送信先ＩＰアドレスが第１判定テーブル１０１に登録されていない場合、分析部５４は、これらを第１判定テーブル１０１に登録する（ステップＳ６０６）。さらに、分析部５４は、取得した時刻情報も、第１判定テーブル１０１に登録する（ステップＳ６０７）。この時刻情報に示された現在時刻は、上記送信元ＩＰアドレスおよび送信先ＩＰアドレスのデータ取得時刻として、第１判定テーブル１０１に記録される。その後、分析部５４は、取得した制御値に応じて最小値と最大値をそれぞれ変更する場合、ステップＳ６０５で説明したように第２判定テーブル１０２を更新する。
【００５７】
以上説明した本実施形態によれば、分析部５４が診断モードである場合には第１実施形態と同様に、異常の要因が特定されるので、的確に対処することが可能となる。さらに、学習モードでは、異常の要因を特定するための第１判定テーブル１０１および第２判定テーブル１０２がそれぞれ自動的に作成される。よって、ユーザの負荷を軽減することが可能になる。
【００５８】
（第３実施形態）
以下、第３実施形態について、第１実施形態および第２実施形態と異なる点を中心に説明する。本実施形態に係る制御システムでは、異常要因判定装置の構成が第１実施形態と異なる。図１２は、第３実施形態に係る異常要因判定装置の構成を示すブロック図である。上述した第１実施形態および第２実施形態と同様の構成要素には同じ符号を付し、詳細な説明を省略する。
【００５９】
図１２に示す異常要因判定装置５０ｂは、表示部５７を有しない点で第１実施形態と異なる。なお、本実施形態においても、異常要因判定装置５０ｂは、ハードウェアで実現されてもよいし、ソフトウェアで実現されてもよい。
【００６０】
異常要因判定装置５０ｂでは、通信インタフェース部５１が、ネットワークスイッチ４０を介して新たにデータを受信すると、第１実施形態と同様に、ヘッダ情報処理、時刻情報判定処理、およびペイロード処理がこの順で行われる。これらの処理フローは、第１実施形態で説明したステップＳ２００のヘッダ情報処理、ステップＳ３００の時刻情報判定処理、およびステップＳ４００のペイロード処理と同様である。
【００６１】
ただし、本実施形態では、異常要因判定装置５０ｂに表示部５７が設けられていない。そのため、各処理の異常ログ確認フローでは、分析部５４は、異常の旨をＨＭＩ２０へ通知する。この場合、ＨＭＩ２０が、異常の旨を表示する。
【００６２】
以上説明した本実施形態によれば、分析部５４が、第１実施形態と同様に異常の要因を特定するので、制御システム１の異常に対して的確に対処することが可能となる。さらに、制御システム１のＨＭＩ２０を活用することで、異常要因判定装置５０ｂは表示機能が不要になる。これにより、異常要因判定装置５０ｂの構成を簡略化でき、装置のコストを低減することができる。
【００６３】
なお、上述した各実施形態では、異常データを１回受信したときに異常判定を行っている。しかし、複数回連続して異常データを受信したときに異常判定を行うこととしてもよい。この場合、異常データの受信回数が、異常判定の回数に到達するまで警告状態として異常ログテーブル１０３に保存してもよい。
【００６４】
以上、いくつかの実施形態および変形例を説明したが、これらの実施形態は、例としてのみ提示したものであり、発明の範囲を限定することを意図したものではない。本明細書で説明した新規なシステムは、その他の様々な形態で実施することができる。また、本明細書で説明したシステムの形態に対し、発明の要旨を逸脱しない範囲内で、種々の省略、置換、変更を行うことができる。添付の特許請求の範囲およびこれに均等な範囲は、発明の範囲や要ことに含まれるこのような形態や変形例を含むように意図されている。
【符号の説明】
【００６５】
１０  制御装置、４０  ネットワークスイッチ、５０、５０ａ、５０ｂ  異常要因判定装置、５３  取得部、５４  分析部、５５  判定テーブル保存部、５６  異常ログ保存部、１０１  第１判定テーブル、１０２  第２判定テーブル
【図１】
2020061717.tif 000003
【図２】
2020061717.tif 000004
【図３】
2020061717.tif 000005
【図４】
2020061717.tif 000006
【図５】
2020061717.tif 000007
【図６】
2020061717.tif 000008
【図７】
2020061717.tif 000009
【図８】
2020061717.tif 000010
【図９】
2020061717.tif 000011
【図１０】
2020061717.tif 000012
【図１１】
2020061717.tif 000013
【図１２】
2020061717.tif 000014