(57)【要約】【課題】セキュリティを確保しながら制御システムの異常を迅速に制御システム側に通知することができる異常診断装置、異常診断システムおよび異常診断方法を提供すること。【解決手段】ネットワークを介したデータ通信により機器を制御する制御システム内に設けられ、制御システムの異常を診断する異常診断装置であって、データ通信で用いられるネットワークデータとして診断データを取得し、取得された診断データを一方向にのみ送信し、かつ、取得された診断データに基づいて制御システムに対する一次異常診断を実施して診断結果を制御システム内に出力する送信側端末と、送信側端末から送信された診断データを受信し、受信された診断データを制御システムに対する二次異常診断を実施する外部診断装置に送信する受信側端末と、を備える。【選択図】図１
2019213058.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介したデータ通信により機器を制御する制御システム内に設けられ、前記制御システムの異常を診断する異常診断装置であって、
前記データ通信で用いられるネットワークデータとして診断データを取得し、前記取得された診断データを一方向にのみ送信し、かつ、前記取得された診断データに基づいて前記制御システムに対する一次異常診断を実施して診断結果を前記制御システム内に出力する送信側端末と、
前記送信側端末から送信された前記診断データを受信し、前記受信された診断データを前記制御システムに対する二次異常診断を実施する外部診断装置に送信する受信側端末と、を備える異常診断装置。
【請求項２】
前記送信側端末は、
前記診断データを入出力する第１通信インタフェース部と、
前記第１通信インタフェース部から出力された前記診断データを転送し、かつ、前記診断データに基づいて前記一次異常診断を実施して診断結果を前記制御システム内に出力する転送・診断部と、
前記一次異常診断における異常の有無の判定に用いられる判定テーブルを保存する判定テーブル保存部と、
前記転送・診断部から転送された前記診断データを一方向にのみ出力する第２通信インタフェース部と、を有し、
前記受信側端末は、
前記第２通信インタフェース部から出力された前記診断データを一方向にのみ入出力する第３通信インタフェース部と、
前記第３通信インタフェース部から出力された前記診断データを転送する転送部と、
前記転送部から転送された前記診断データを入力して前記外部診断装置に出力する第４通信インタフェース部と、を有する請求項１に記載の異常診断装置。
【請求項３】
前記送信側端末は、前記送信側端末の負荷を計測する負荷計測部を更に備え、
前記転送・診断部は、前記負荷計測部で計測された前記負荷が許容値を超えた場合には、前記一次異常診断のうちの少なくとも一部の診断を省略し、前記省略された診断を指示する診断指示信号を前記受信側端末に送信し、
前記受信側端末は、前記診断指示信号を受信して前記外部診断装置に送信する、請求項２に記載の異常診断装置。
【請求項４】
前記送信側端末は、前記転送・診断部の動作モードを診断モードと学習モードとの間で切り替えるモード切替部を更に備え、
前記転送・診断部は、前記診断モードでは、前記判定テーブルに基づいて前記一次異常診断を実施し、前記学習モードでは、前記送信側端末に入力された前記判定テーブルを前記判定テーブル保存部に登録する、請求項２に記載の異常診断装置。
【請求項５】
前記一次異常診断は、前記制御システムがセキュリティ異常を有するか否かの診断を含み、
前記判定テーブル保存部は、前記判定テーブルとして前記ネットワークデータのパケットのヘッダ情報を保存し、
前記転送・診断部は、前記診断データが前記判定テーブル保存部に保存された前記ヘッダ情報を有しない場合に、前記制御システムが前記セキュリティ異常を有する旨の診断結果を出力する、請求項２に記載の異常診断装置。
【請求項６】
前記一次異常診断は、前記制御システムがセキュリティ攻撃を受けているか否かの診断を含み、
前記転送・診断部は、規定時間内の前記診断データの受信パケット数を解析し、前記受信パケット数が規定数を超えた場合に、前記制御システムがセキュリティ攻撃を受けている旨の診断結果を出力する、請求項２に記載の異常診断装置。
【請求項７】
ネットワークを介したデータ通信により機器を制御する制御システム内に設けられ、前記制御システムの異常を診断する異常診断装置と、
前記制御システムの外部に設けられた外部診断装置と、を備え、
前記異常診断装置は、
前記データ通信で用いられるネットワークデータとして診断データを取得し、前記取得された診断データを一方向にのみ送信し、かつ、前記取得された診断データに基づいて前記制御システムに対する一次異常診断を実施して診断結果を前記制御システム内に出力する送信側端末と、
前記送信側端末から送信された前記診断データを受信し、前記受信された診断データを前記外部診断装置に送信する受信側端末と、を備え、
前記外部診断装置は、
前記受信側端末から送信された前記診断データに基づいて、前記制御システムに対する二次異常診断を実施して診断結果を前記制御システムに接続されていないユーザ端末に送信する、異常診断システム。
【請求項８】
ネットワークを介したデータ通信により機器を制御する制御システムの異常を診断する異常診断方法であって、
前記データ通信で用いられるネットワークデータとして診断データを前記制御システム内において取得し、
前記取得された診断データを前記制御システム内において一方向にのみ送信し、かつ、前記取得された診断データに基づいて前記制御システムに対する一次異常診断を実施して診断結果を前記制御システム内に出力し、
前記一方向にのみ送信された前記診断データを前記制御システム内において受信し、前記受信された診断データを前記制御システムに対する二次異常診断を実施する外部診断装置に送信する、異常診断方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明による実施形態は、異常診断装置、異常診断システムおよび異常診断方法に関する。
【背景技術】
【０００２】
プラント等に設置された機器を制御する制御システムでは、近年、オープンネットワーク化が進んでいる。このような制御システムでは、ネットワークのセキュリティ対策が重要になる。
【０００３】
ネットワークのセキュリティを確保するための技術として、クラウド上のリモート監視端末に向けて一方向にのみデータを送信可能なデータダイオードと呼ばれる装置が知られている。また、データダイオードの他にも、ネットワークの情報からセキュリティに関する異常を検知するＩＤＳ（Ｉｎｔｒｕｓｉｏｎ  Ｄｅｔｅｃｔｉｏｎ  Ｓｙｓｔｅｍ）と呼ばれる装置が知られている。
【０００４】
しかしながら、データダイオードを制御システムに適用した場合、データは現場（制御システム）側からクラウド側に向けて一方向にのみ送信されるため、クラウド側で異常を検知しても現場側に異常を通知することができないといった問題がある。
【０００５】
また、ＩＤＳを制御システムに適用した場合、制御システムの制御周期内に異常の検知処理が完了しない場合に、データが逐次蓄積されていくため、すべてのデータが検知処理に必要な場合、データの増加により検知が遅れてしまうといった問題がある。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２０１２−１６９７３１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
本発明は上述した点を考慮してなされたものであり、セキュリティを確保しながら制御システムの異常を制御システム側に迅速に通知することができる異常診断装置、異常診断システムおよび異常診断方法を提供することを目的とする。
【課題を解決するための手段】
【０００８】
本実施形態による異常診断装置は、
ネットワークを介したデータ通信により機器を制御する制御システム内に設けられ、前記制御システムの異常を診断する異常診断装置であって、
前記データ通信で用いられるネットワークデータとして診断データを取得し、前記取得された診断データを一方向にのみ送信し、かつ、前記取得された診断データに基づいて前記制御システムに対する一次異常診断を実施して診断結果を前記制御システム内に出力する送信側端末と、
前記送信側端末から送信された前記診断データを受信し、前記受信された診断データを前記制御システムに対する二次異常診断を実施する外部診断装置に送信する受信側端末と、を備える。
【発明の効果】
【０００９】
本発明によれば、セキュリティを確保しながら制御システムの異常を制御システム側に迅速に通知することができる。
【図面の簡単な説明】
【００１０】
【図１】第１の実施形態による異常診断システムを示すブロック図である。
【図２Ａ】第１の実施形態による異常診断装置を示すブロック図である。
【図２Ｂ】第１の実施形態によるクラウド診断装置を示すブロック図である。
【図３Ａ】第１の実施形態による異常診断装置の送信側端末の動作例を示すフローチャートである。
【図３Ｂ】第１の実施形態による異常診断装置の受信側端末の動作例を示すフローチャートである。
【図４】第１の実施形態による異常診断装置の動作例において、第１判定テーブルを示す図である。
【図５】第１の実施形態による異常診断装置の送信側端末の動作例において、ヘッダ情報判定処理を示すフローチャートである。
【図６Ａ】第１の実施形態による異常診断装置の動作例において、不正端末の接続による異常の通知画面を示す図である。
【図６Ｂ】第１の実施形態による異常診断装置の動作例において、端末の不正利用による異常の通知画面を示す図である。
【図７】第１の実施形態による異常診断装置の送信側端末の動作例において、統計情報判定処理を示すフローチャートである。
【図８】第１の実施形態による異常診断装置の動作例において、不正攻撃による異常の通知画面を示す図である。
【図９Ａ】第１の実施形態による異常診断システムのクラウド診断装置の動作例を示すフローチャートである。
【図９Ｂ】第１の実施形態による異常診断システムのクラウド診断装置の動作例において、ＤＰＩ判定処理を示すフローチャートである。
【図１０】第１の実施形態による異常診断システムのクラウド診断装置の動作例において、ＤＰＩ判定処理に用いられる第２判定テーブルを示す図である。
【図１１】第１の実施形態による異常診断システムのクラウド診断装置の動作例において、ＤＰＩ判定処理の変形例を示すフローチャートである。
【図１２Ａ】第２の実施形態による異常診断装置を示すブロック図である。
【図１２Ｂ】第２の実施形態によるクラウド診断装置を示すブロック図である。
【図１３Ａ】第２の実施形態による異常診断装置の送信側端末の動作例を示すフローチャートである。
【図１３Ｂ】第２の実施形態による異常診断装置の送信側端末の動作例において、負荷計測を示すフローチャートである。
【図１３Ｃ】第２の実施形態による異常診断装置の送信側端末の動作の変形例を示すフローチャートである。
【図１３Ｄ】第２の実施形態による異常診断システムのクラウド診断装置の動作例を示すフローチャートである。
【図１４Ａ】第３の実施形態による異常診断装置を示すブロック図である。
【図１４Ｂ】第３の実施形態によるクラウド診断装置を示すブロック図である。
【図１５Ａ】第３の実施形態による異常診断システムの送信側端末の動作例を示すフローチャートである。
【図１５Ｂ】第３の実施形態による異常診断システムのクラウド診断装置の動作例を示すフローチャートである。
【発明を実施するための形態】
【００１１】
以下、図面を参照して本発明に係る実施形態を説明する。本実施形態は、本発明を限定するものではない。
【００１２】
（第１の実施形態）
図１は、第１の実施形態による異常診断システム１を示すブロック図である。第１の実施形態による異常診断システム１は、例えば、プラントやＦＡ(Factory Automation)等に設置された機器を制御するシステムの異常を診断するために用いることができる。
【００１３】
図１に示すように、異常診断システム１は、制御システム２と、外部診断装置の一例であるクラウド診断装置３と、を備える。
【００１４】
制御システム２は、ネットワークを介したデータ通信により機器を制御する。ネットワークは、例えば、Ｅｔｈｅｒｎｅｔ（登録商標）であってもよいが、これに限定されない。
【００１５】
機器を制御するための具体的な構成として、図１に示すように、制御システム２は、複数の制御装置４（Ａ〜Ｃ）と、ＨＭＩ(Human Machine Interface)５と、ツール６と、ネットワークスイッチ（ＳＷ）７と、異常診断装置８と、を有する。
【００１６】
複数の制御装置４は、制御システム２内に設けられ、データ通信で用いられるネットワークデータに基づいて機器を制御する装置である。
【００１７】
ＨＭＩ５は、ネットワークを介して制御装置４に接続され、ネットワークを介して制御装置４の状態監視を行う装置である。制御装置４は、機器を制御するための制御プログラムを実行することで、機器を制御する。
【００１８】
ツール６は、ネットワークを介して制御装置４の制御プログラムを変更するエンジニアリングツールである。
【００１９】
ネットワークスイッチ７は、制御装置４を含めた制御システム２の各構成部４、５、６、８をネットワークに接続する装置である。ネットワークスイッチ７は、ミラーポートを有し、ミラーポートによってネットワークデータをコピーすることで、ネットワークデータとして診断データを生成する。診断データは、異常診断装置８による制御システム２の異常の診断に用いられる。すなわち、異常診断装置８は、ネットワークスイッチ７のミラーポートを介して、制御システム２内に流れるすべてのパケットを取得して制御システム２の異常の診断に用いることができる。なお、異常診断装置８は、ミラーポートに限らず、例えば、制御システム２内のネットワークデータの伝送形態をマルチキャスト伝送とすることで、制御システム２内のすべてのネットワークデータを取得して異常診断に用いてもよい。
【００２０】
異常診断装置８は、ネットワークを介したデータ通信により機器を制御する制御システム２内に設けられ、制御システム２の異常を診断する装置である。
【００２１】
図２Ａは、第１の実施形態による異常診断装置８を示すブロック図である。図２Ａに示すように、異常診断装置８は、送信側端末８１と、受信側端末８２とを有する。送信側端末８１と受信側端末８２とは、送信側から受信側への一方向のみの伝送が可能なインタフェース８３で接続されている。インタフェース８３は、例えば、光ケーブルであってもよい。送信側端末８１と受信側端末８２とは、同一の筐体内に配置されても良いし、別々の筐体内に配置されてもよい。
【００２２】
セキュリティを確保しながら制御システム２の異常を制御システム２側（すなわち、現場側）に迅速に通知することを意図して、送信側端末８１および受信側端末８２は、以下のように構成されている。
【００２３】
送信側端末８１は、データ通信で用いられるネットワークデータとして診断データを取得し、取得された診断データを一方向にのみ送信し、かつ、取得された診断データに基づいて制御システム２に対する一次異常診断を実施して診断結果を制御システム２内に出力する。
【００２４】
受信側端末８２は、送信側端末８１から送信された診断データを受信し、受信された診断データを、一次異常診断よりも詳細な制御システム２に対する二次異常診断を実施するクラウド診断装置３に送信する。
【００２５】
送信側端末８１および受信側端末８２によれば、診断データを一方向のみに送信可能なことで外部からのアクセスが禁止された制御システム２内で、一次異常診断を実施して診断結果を制御システム２内に出力することができる。これにより、セキュリティを確保しながら制御システム２側での診断結果の取得を確保することができる。また、全ての診断データを制御システム２内で診断するのではなく、一次異常診断よりも時間がかかる二次異常診断をクラウド診断装置３に分担させることができる。これにより、診断データのデータ量が多い場合でも、制御システム２側での診断の遅延が生じることを抑制することができる。
【００２６】
より詳しくは、図２Ａに示すように、送信側端末８１は、第１通信インタフェース部（第１通信Ｉ／Ｆ）８１１と、転送・診断部８１２と、第１判定テーブル保存部８１３と、第２通信インタフェース部（第２通信Ｉ／Ｆ）８１４と、を有する。
【００２７】
第１通信インタフェース部８１１は、診断データを入出力する。より詳しくは、第１通信インタフェース部８１１は、ネットワークスイッチ７で生成された診断データを入力し、入力された診断データを転送・診断部８１２に出力する。
【００２８】
転送・診断部８１２は、第１通信インタフェース部８１１から出力された診断データを第２通信インタフェース部８１４に転送し、かつ、診断データに基づいて一次異常診断を実施して診断結果を制御システム２内に出力する。例えば、転送・診断部８１２は、第１通信インタフェース部８１１を介して一次異常診断の診断結果を制御装置４やＨＭＩ５に出力する。
【００２９】
第１判定テーブル保存部８１３は、一次異常診断における異常の有無の判定に用いられる第１判定テーブルを保存する。
【００３０】
第２通信インタフェース部８１４は、転送・診断部８１２から転送された診断データを一方向にのみ出力する。
【００３１】
これら送信側端末８１の各構成部８１１〜８１４は、ハードウェアで構成されてもよいし、ソフトウェアで構成されてもよい。
【００３２】
このように構成された送信側端末８１によれば、第２通信インタフェース部８１４によって診断データの一方向性すなわちセキュリティを確保しながら、転送・診断部８１２によって第１判定テーブルを用いた制御システム２内での一次異常診断を実施することができる。
【００３３】
一次異常診断は、制御システム２がセキュリティ異常を有するか否かの診断を含んでもよい。この場合、第１判定テーブル保存部８１３は、第１判定テーブルとしてネットワークデータのパケットのヘッダ情報を保存してもよい。そして、転送・診断部８１２は、診断データが第１判定テーブル保存部８１３に保存されたヘッダ情報を有しない場合に、制御システム２がセキュリティ異常を有する旨の診断結果を出力してもよい。このような構成によれば、診断データのうちのペイロード部と比較して判定が容易なヘッダ情報を対象とした診断を行うことで、一次異常診断の診断結果を迅速に取得することができる。
【００３４】
また、一次異常診断は、制御システム２がＤｏＳ攻撃と呼ばれる大量のネットワークデータを送信するセキュリティ攻撃を受けているか否かの診断を含んでもよい。この場合、送信側端末８１は、規定時間内の診断データの受信パケット数を解析し、受信パケット数が規定数を超えた場合に、制御システム２がセキュリティ攻撃を受けている旨の診断結果を出力してもよい。このような構成によれば、セキュリティを確保しながら、セキュリティ攻撃の診断結果を迅速に取得することができる。
【００３５】
一方、図２Ａに示すように、受信側端末８２は、第３通信インタフェース部（第３通信Ｉ／Ｆ）８２１と、転送部８２２と、第４通信インタフェース部（第４通信Ｉ／Ｆ）８２３と、を有する。
【００３６】
第３通信インタフェース部８２１は、第２通信インタフェース部８１４から出力された診断データを一方向にのみ入出力する。
【００３７】
転送部８２２は、第３通信インタフェース部８２１から出力された診断データを第４通信インタフェース部８２３に転送する。
【００３８】
第４通信インタフェース部８２３は、転送部８２２から転送された診断データを入力してクラウド診断装置３に出力する。
【００３９】
これら受信側端末８２の各構成部８２１〜８２３は、ハードウェアで構成されてもよいし、ソフトウェアで構成されてもよい。
【００４０】
このように構成された受信側端末８２によれば、第３通信インタフェース部８２１によって診断データの一方向性すなわちセキュリティを確保しながら、二次異常診断のための診断データの転送を行うことができる。
【００４１】
図２Ｂは、第１の実施形態によるクラウド診断装置３を示すブロック図である。クラウド診断装置３は、制御システム２の外部に設けられている。
【００４２】
クラウド診断装置３は、受信側端末８２から送信された診断データに基づいて、制御システム２に対する二次異常診断を実施して診断結果を制御システム２に接続されていないユーザ端末９に送信する。
【００４３】
クラウド診断装置３によれば、一次異常診断よりも詳細な二次異常診断を分担することで、制御システム２の異常診断装置８側での診断の遅延を抑制することができる。また、二次異常診断の診断結果を制御システム２に接続されていないユーザ端末９に送信することで、端末９を所持するユーザは、制御システム２が設置されている場所に居ながら、セキュリティを確保しつつ詳細な二次異常診断の結果を取得することができる。
【００４４】
より詳しくは、  図２Ｂに示すように、クラウド診断装置３は、第５通信インタフェース部３１と、診断部３２と、第２判定テーブル保存部３３と、通知部３４とを有する。
【００４５】
第５通信インタフェース部３１は、診断データを入出力する。より詳しくは、第５通信インタフェース部３１は、異常診断装置８から送信された診断データを入力し、入力された診断データを診断部３２に出力する。
【００４６】
診断部３２は、第５通信インタフェース部３１から出力された診断データに基づいて二次異常診断を実施して診断結果を通知部３４に出力する。
【００４７】
通知部３４は、診断部３２から入力された二次異常診断の診断結果をユーザ端末９に送信する。
【００４８】
これらクラウド診断装置３の各構成部３１〜３４は、ハードウェアで構成されてもよいし、ソフトウェアで構成されてもよい。
【００４９】
二次異常診断は、一次異常診断よりも詳細な（すなわち、診断時間がかかる）制御システム２の異常の有無の診断である。クラウド診断装置３は、診断データのペイロード部が予め設定された範囲の制御値を有しない場合、または、ペイロード部に含まれる健全性確認データが更新されていない場合に、制御システム２が異常を有する旨の診断結果を出力してもよい。このような構成によれば、ヘッダ情報と比較して診断に時間がかかるペイロード部を対象とした診断をクラウド診断装置３で分担することで、異常診断装置８の診断に遅延が生じることを有効に抑制することができる。
【００５０】
（動作例）
次に、以上のように構成された第１の実施形態による異常診断システム１の動作例について説明する。
【００５１】
図３Ａは、第１の実施形態による異常診断装置８の送信側端末８１の動作例を示すフローチャートである。第１の実施形態による異常診断システム１のうち、異常診断装置８の送信側端末８１は、図３Ａのフローチャートにしたがって動作する。図３Ａのフローチャートは、必要に応じて繰り返される。
【００５２】
具体的には、先ず、転送・診断部８１２は、診断データの転送処理および一次異常診断処理を開始した後（ステップＳ１）、新規の診断データが受信されたか否かを判定する（ステップＳ２）。
【００５３】
新規の診断データが受信された場合（ステップＳ２：Ｙｅｓ）、転送・診断部８１２は、第１通信インタフェース部８１１で受信された新規の診断データを、第２通信インタフェース部８１４を介して受信側端末８２に転送する（ステップＳ３）。
【００５４】
一方、新規の診断データが受信されていない場合（ステップＳ２：Ｎｏ）、転送・診断部８１２は、新規の診断データが受信されたか否かの判定を繰り返す（ステップＳ２）。
【００５５】
新規の診断データを受信した後、転送・診断部８１２は、受信された新規の診断データに基づいて、一次異常診断処理のうちのヘッダ情報判定処理を実行する（ステップＳ４）。
【００５６】
図４は、第１の実施形態による異常診断装置８の動作例において、第１判定テーブルを示す図である。ヘッダ情報判定処理には、第１判定テーブル保存部８１３に保存された第１判定テーブルとして、図４に示される第１判定テーブルを用いることができる。
【００５７】
図４の例において、第１判定テーブルは、予め通信しうる端末の情報として、送信元ＩＰアドレスと、送信先ＩＰアドレスとがプリセットされるテーブルで構成されている。また、第１判定テーブルは、行ごとに番号が付与されている。
【００５８】
図５は、第１の実施形態による異常診断装置８の送信側端末８１の動作例において、ヘッダ情報判定処理を示すフローチャートである。第１判定テーブルを用いたヘッダ情報判定処理は、図５のフローチャートにしたがって実行される。
【００５９】
具体的には、先ず、ヘッダ情報判定処理を開始した後（ステップＳ４１）、転送・診断部８１２は、第１判定テーブルの中からｉ番目の送信元ＩＰアドレスおよび送信先ＩＰアドレスを探索する（ステップＳ４２）。なお、ｉの初期値は１である。
【００６０】
ｉ番目の送信元ＩＰアドレスおよび送信先ＩＰアドレスを探索した後、転送・診断部８１２は、新規の診断データの送信元ＩＰアドレスおよび送信先ＩＰアドレスと、ｉ番目の送信元ＩＰアドレスおよび送信先ＩＰアドレスとを比較し、両者が一致するか否かを判定する（ステップＳ４３）。
【００６１】
新規の診断データの送信元ＩＰアドレスおよび送信先ＩＰアドレスと、ｉ番目の送信元ＩＰアドレスおよび送信先ＩＰアドレスとが一致する場合（ステップＳ４３：Ｙｅｓ）、転送・診断部８１２は、制御システム２が正常であると判定する（ステップＳ４４）。
【００６２】
一方、新規の診断データの送信元ＩＰアドレスおよび送信先ＩＰアドレスと、ｉ番目の送信元ＩＰアドレスおよび送信先ＩＰアドレスとが一致しない場合（ステップＳ４３：Ｎｏ）、転送・診断部８１２は、新規の診断データの送信元ＩＰアドレスと、ｉ番目の送信元ＩＰアドレスとが一致するか否かを判定する（ステップＳ４５）。
【００６３】
新規の診断データの送信元ＩＰアドレスとｉ番目の送信元ＩＰアドレスとが一致する場合（ステップＳ４５：Ｙｅｓ）、転送・診断部８１２は、フラグＦＬＧの値を「１」にセットする（ステップＳ４６）。
【００６４】
フラグＦＬＧの値を「１」にセットした後、または、新規の診断データの送信元ＩＰアドレスとｉ番目の送信元ＩＰアドレスとが一致しない場合（ステップＳ４５：Ｎｏ）、転送・診断部８１２は、第１判定テーブルの全行のＩＰアドレスの探索が終了したか否かを判定する（ステップＳ４７）。
【００６５】
第１判定テーブルの全行のＩＰアドレスの探索が終了した場合（ステップＳ４７：Ｙｅｓ）、転送・診断部８１２は、フラグＦＬＧが「１」にセットされているか否かを判定する（ステップＳ４８）。
【００６６】
一方、第１判定テーブルの全行のＩＰアドレスの探索が終了していない場合（ステップＳ４７：Ｎｏ）、転送・診断部８１２は、ｉをインクリメントして第１判定テーブル内の次行のＩＰアドレスの探索に移行する（ステップＳ４９）。
【００６７】
フラグＦＬＧが「１」にセットされていない場合（ステップＳ４８：Ｎｏ）、送信元ＩＰアドレスが第１判定テーブル保存部８１３に保存されていないことになる。この場合、転送・診断部８１２は、制御システム２が異常である、すなわち、不正な端末がネットワークに接続されたと判定する（ステップＳ４１０）。
【００６８】
不正な端末がネットワークに接続されたと判定した後、転送・診断部８１２は、その旨をユーザに通知する（ステップＳ４１１）。
【００６９】
図６Ａは、第１の実施形態による異常診断装置８の動作例において、不正端末の接続による異常の通知画面を示す図である。例えば、転送・診断部８１２は、図６Ａの通知画面をＨＭＩ５の表示部に表示することで、不正な端末がネットワークに接続された旨をユーザに通知する。
【００７０】
不正な端末がネットワークに接続された旨をユーザに通知した後、転送・診断部８１２は、フラグＦＬＧを「０」にセット（ステップＳ４１２）したうえで、ヘッダ情報判定処理を終了する（ステップＳ４１３）。
【００７１】
一方、フラグＦＬＧが「１」にセットされている場合（ステップＳ４８：Ｙｅｓ）、送信先ＩＰアドレスは第１判定テーブルに存在しないが、送信元ＩＰアドレスは第１判定テーブルに存在していることになる。この場合、転送・診断部８１２は、制御システム２が異常である、すなわち、端末が不正に操作され、情報が漏洩していると判定する（ステップＳ４１４）。
【００７２】
端末が不正に操作され、情報が漏洩していると判定した後、転送・診断部８１２は、その旨をユーザに通知する（ステップＳ４１５）。
【００７３】
図６Ｂは、第１の実施形態による異常診断装置８の動作例において、端末の不正利用による異常の通知画面を示す図である。例えば、転送・診断部８１２は、図６Ｂの通知画面をＨＭＩ５の表示部に表示することで、端末が不正に操作され、情報が漏洩している旨をユーザに通知する。
【００７４】
なお、ＩＰアドレスを用いたヘッダ情報判定処理について説明したが、ヘッダ情報判定処理には、ＩＰアドレスに加えて、または、ＩＰアドレスに代えて、診断データのＭＡＣアドレス、送信回数、頻度などを用いることもできる。また、セキュリティの判定をより厳密化するため、送信元ＩＰアドレスおよび送信先ＩＰアドレスに加え、プロトコル情報を加味してもよい。この場合、例えば、第１判定テーブルに保存されたプロトコル情報がＴＣＰやＵＤＰであるのに対して、新規の診断データのプロトコルがＳＳＨである場合には、不正な端末がネットワークに接続されたと判定してもよい。これにより送信元ＩＰアドレスおよび送信先ＩＰアドレスが同一でも、不正なプロトコルでアクセスを試みているケースが抽出可能になる。
【００７５】
ヘッダ情報判定処理を終了した後、図３Ａに示すように、転送・診断部８１２は、受信された新規の診断データに基づいて、一次異常診断処理のうちの統計情報判定処理を実行する（ステップＳ５）。
【００７６】
図７は、第１の実施形態による異常診断装置８の送信側端末８１の動作例において、統計情報判定処理を示すフローチャートである。統計情報判定処理は、図７のフローチャートにしたがって行われる。
【００７７】
具体的には、先ず、転送・診断部８１２は、統計情報判定処理を開始した後（ステップＳ５１）、新規の診断データの受信に応じてインクリメントされるカウンタ変数およびタイマの計測時間を初期化（ｉ＝０、timer＝０）する（ステップＳ５２）。
【００７８】
カウンタ変数を初期化した後、転送・診断部８１２は、新規の診断データを受信する（ステップＳ５３）。
【００７９】
新規の診断データを受信した後、転送・診断部８１２は、カウンタ変数をインクリメント（ｉ++）する（ステップＳ５４）。
【００８０】
カウンタ変数をインクリメントした後、転送・診断部８１２は、カウンタ変数が規定数ｉ＿ｔｈを超えたか否かを判定する（ステップＳ５５）。規定数ｉ＿ｔｈは予め決めておいてもよいし、動的にユーザが変更可能なものでもよい。
【００８１】
カウンタ変数が規定数ｉ＿ｔｈを超えた場合（ステップＳ５５：Ｙｅｓ）、転送・診断部８１２は、制御システム２が異常であると判定する（ステップＳ５６）。より詳しくは、転送・診断部８１２は、制御システム２がＤｏＳ攻撃などのサービス不能攻撃を受信していると判定する。
【００８２】
図８は、第１の実施形態による異常診断装置８の動作例において、不正攻撃による異常の通知画面を示す図である。例えば、転送・診断部８１２は、図８の通知画面をＨＭＩ５の表示部に表示することで、サービス不能攻撃を受けている旨をユーザに通知する。
【００８３】
カウンタ変数が規定数ｉ＿ｔｈを超えていない場合（ステップＳ５５：Ｎｏ）、転送・診断部８１２は、タイマの計測時間が規定時間ｔｉｍｅ＿ｔｈを超えたか否かを判定する（ステップＳ５７）。
【００８４】
タイマの計測時間が規定時間ｔｉｍｅ＿ｔｈを超えた場合（ステップＳ５７：Ｙｅｓ）、転送・診断部８１２は、タイマの計測時間とカウンタ変数とをクリアしたうえで新規の診断データの受信に遷移する（ステップＳ５３）。
【００８５】
一方、タイマの計測時間が規定時間ｔｉｍｅ＿ｔｈを超えていない場合（ステップＳ５７：Ｎｏ）、転送・診断部８１２は、制御システム２が正常であると判定して統計情報判定処理を終了する（ステップＳ５８）。
【００８６】
図３Ｂは、第１の実施形態による異常診断装置８の受信側端末８２の動作例を示すフローチャートである。第１の実施形態による異常診断システム１のうち、異常診断装置８の受信側端末８２は、図３Ｂのフローチャートにしたがって動作する。図３Ｂのフローチャートは、必要に応じて繰り返される。
【００８７】
具体的には、先ず、転送部８２２は、診断データの転送処理を開始した後（ステップＳ１１）、新規の診断データが受信されたか否かを判定する（ステップＳ１２）。
【００８８】
新規の診断データが受信された場合（ステップＳ１２：Ｙｅｓ）、転送部８２２は、第３通信インタフェース部８２１で受信された新規の診断データを、第４通信インタフェース部８２３を介してクラウド診断装置３に転送する（ステップＳ１３）。
【００８９】
一方、新規の診断データが受信されていない場合（ステップＳ１２：Ｎｏ）、転送部８２２は、新規の診断データが受信されたか否かの判定を繰り返す（ステップＳ１２）。
【００９０】
図９Ａは、第１の実施形態による異常診断システム１のクラウド診断装置３の動作例を示すフローチャートである。第１の実施形態による異常診断システム１のうち、クラウド診断装置３は、図９Ａのフローチャートにしたがって動作する。図９Ａのフローチャートは、必要に応じて繰り返される。
【００９１】
具体的には、先ず、診断部３２は、二次異常診断処理を開始した後（ステップＳ６１）、新規の診断データが受信されたか否かを判定する（ステップＳ６２）。
【００９２】
新規の診断データが受信された場合（ステップＳ６２：Ｙｅｓ）、診断部３２は、第５通信インタフェース部３１で受信された新規の診断データに基づいて、二次異常診断処理としてＤＰＩ(Deep Packet Inspection)判定処理を行う（ステップＳ６３）。なお、二次異常診断処理は、更に、既述した統計情報判定処理を含んでもよい。
【００９３】
図９Ｂは、第１の実施形態による異常診断システム１のクラウド診断装置３の動作例において、ＤＰＩ判定処理を示すフローチャートである。図１０は、第１の実施形態による異常診断システム１のクラウド診断装置３の動作例において、ＤＰＩ判定処理に用いられる第２判定テーブルを示す図である。図１０の第２判定テーブルは、ネットワークデータのペイロード部を構成するフィールド（Ｎｏ１〜）毎に、制御値の最小値および最大値と、周期的に値が増加する時刻データの前回値が格納されている。時刻データは、制御システム２の健全性の確認に用いることができる。ＤＰＩ判定処理は、図１０の第２判定テーブルを用いて図９Ｂのフローチャートにしたがって実行される。
【００９４】
具体的には、診断部３２は、ＤＰＩ判定処理を開始した後（ステップＳ６３１）、第２判定テーブルの中からｉ番目のフィールドを探索する（ステップＳ６３２）。なお、ｉの初期値は１である。
【００９５】
第２の判定テーブルからｉ番目のフィールドを探索した後、診断部３２は、探索されたｉ番目のフィールドに基づいて、新規の診断データのｉ番目のフィールドが正常であるか否かを判定する（ステップＳ６３３）。
【００９６】
例えば、診断部３２は、新規の診断データのｉ番目のフィールドの制御値が、第２判定テーブルのｉ番目のフィールドの制御値の最小値と最大値との間の範囲内であるか否かを判定する。また、診断部３２は、新規の診断データのｉ番目のフィールドの時刻データが、第２判定テーブルのｉ番目のフィールドの前回値から更新されているか否かを判定する。そして、新規の診断データの制御値が最小値と最大値との間の範囲内であり、かつ、新規の診断データの時刻データ（すなわち、健全性確認データ）が前回値から更新されている場合に、制御システム２が正常であると判定し、そうでない場合に、制御システム２が異常であると判定する。
【００９７】
新規の診断データのｉ番目のフィールドが正常である場合（ステップＳ６３３：Ｙｅｓ）、診断部３２は、全てのフィールドの探索が終了したか否かを判定する（ステップＳ６３４）。
【００９８】
一方、新規の診断データのｉ番目のフィールドが異常である場合（ステップＳ６３３：Ｎｏ）、診断部３２は、制御システム２が異常であると判定する（ステップＳ６３５）。この場合、診断部３２は、携帯回線等の異常診断システム１の通信回線以外の通信回線を用いて、ユーザ端末９に制御システム２の異常を通知する。
【００９９】
全てのフィールドの探索が終了した場合（ステップＳ６３４：Ｙｅｓ）、診断部３２は、制御システム２が正常であると判定してＤＰＩ判定処理を終了する（ステップＳ６３６）。
【０１００】
一方、全てのフィールドの探索が終了していない場合（ステップＳ６３４：Ｎｏ）、診断部３２は、ｉをインクリメントして次のフィールドの探索に遷移する（ステップＳ６３７）。
【０１０１】
図１１は、第１の実施形態による異常診断システム１のクラウド診断装置３の動作例において、ＤＰＩ判定処理の変形例を示すフローチャートである。診断データが共通鍵で暗号化されている場合、図１１に示すように、診断部３２は、ＤＰＩ判定処理を開始した後（ステップＳ６３１）、制御システム２内の共通鍵から復号化アルゴリズムを適用して復号処理（ステップＳ６３８）を行えばよい。そして、復号化された診断データに基づいて、ＤＰＩ判定処理を実行すればよい。診断データの暗号化方式については、共通鍵方式のものであればアルゴリズムは問わない。
【０１０２】
第１の実施形態によれば、セキュリティが確保された分散型アーキテクチャを構築でき、制御システム２の伝送パケットの一次異常診断を現場側で実施し、詳細な二次異常診断をクラウド側で実施することができる。これにより、セキュリティを確保しつつ、現場側の診断結果については制御システム２へ直接通知が可能になり、詳細な診断結果はユーザへ通知することが可能になる。すなわち、第１の実施形態によれば、セキュリティを確保しながら制御システム２の異常を制御システム２側に迅速に通知することができる。
【０１０３】
（第２の実施形態）
次に、送信側端末８１の負荷に応じて一次異常診断をクラウド側で分担する第２の実施形態について説明する。
【０１０４】
図１２Ａは、第２の実施形態による異常診断装置８を示すブロック図である。
【０１０５】
第２の実施形態において、送信側端末８１は、第１の実施形態の構成に加えて、更に、負荷計測部８１５を有する。負荷計測部８１５は、送信側端末８１の負荷を計測する。
【０１０６】
送信側端末８１の転送部８２２は、負荷計測部８１５で計測された負荷が許容値を超えた場合には、一次異常診断のうちの少なくとも一部の診断を省略する。そして、転送・診断部８１２は、省略された診断をクラウド診断装置３の診断部３２に指示するため、診断指示信号の一例である診断モード切替信号を受信側端末８２に送信する。
【０１０７】
受信側端末８２の転送部８２２は、送信側端末８１の転送・診断部８１２から送信された診断モード切替信号を受信してクラウド診断装置３に送信する。
【０１０８】
図１２Ｂは、第２の実施形態によるクラウド診断装置３を示すブロック図である。
【０１０９】
第２の実施形態において、クラウド診断装置３は、第１の実施形態の構成に加えて、更に、診断切替部３５と、表示部３６とを有する。
【０１１０】
診断切替部３５は、転送部８２２から送信された診断モード切替信号に応じて、二次異常診断に加えて転送・診断部８１２で省略された一次異常診断の診断項目も診断するように診断部３２の診断モードを切り替える。
【０１１１】
表示部３６は、診断部３２で判定された制御システム２の異常状態や、トレンド情報を表示する。
【０１１２】
（動作例）
次に、以上のように構成された第２の実施形態による異常診断システム１の動作例について説明する。
【０１１３】
図１３Ａは、第２の実施形態による異常診断装置８の送信側端末８１の動作例を示すフローチャートである。第２の実施形態による異常診断システム１のうち、異常診断装置８の送信側端末８１は、図１３Ａのフローチャートにしたがって動作する。図１３Ａのフローチャートは、必要に応じて繰り返される。
【０１１４】
具体的には、負荷計測部８１５は、図３Ａで説明したデータ転送（ステップＳ３）の後に、送信側端末８１の負荷を計測する（ステップＳ７）。
【０１１５】
図１３Ｂは、第２の実施形態による異常診断装置８の送信側端末８１の動作例において、負荷計測を示すフローチャートである。負荷計測は、図１３Ｂのフローチャートにしたがって実行される。
【０１１６】
具体的には、負荷計測部８１５は、負荷計測を開始した後（ステップＳ７１）、送信側端末８１のＣＰＵの使用率（％）が許容値ＣＰＵ＿ｔｈを超えたか否かを判定する（ステップＳ７２）。
【０１１７】
ＣＰＵの使用率が許容値ＣＰＵ＿ｔｈを超えた場合（ステップＳ７２：Ｙｅｓ）、診断切替部３５は、転送・診断部８１２から送信された診断モード切替信号に応じて、診断モードを切り替える（ステップＳ７３）。これにより、診断部３２は、通常の二次異常診断に加えて、送信側端末８１の転送・診断部８１２が省略した一次異常診断の診断項目の診断を実施する。
【０１１８】
一方、ＣＰＵの使用率が許容値ＣＰＵ＿ｔｈを超えていない場合（ステップＳ７２：Ｎｏ）、負荷計測部８１５は、診断データの伝送負荷率（ｐｐｓ）が許容値Ｔｒａｎｓ＿ｔｈを超えたか否かを判定する（ステップＳ７４）。
【０１１９】
診断データの伝送負荷率（ｐｐｓ）が許容値Ｔｒａｎｓ＿ｔｈを超えた場合（ステップＳ７４：Ｙｅｓ）、診断切替部３５は、転送・診断部８１２から送信された診断モード切替信号に応じて、診断モードを切り替える（ステップＳ７３）。
【０１２０】
一方、診断データの伝送負荷率（ｐｐｓ）が許容値Ｔｒａｎｓ＿ｔｈを超えていない場合（ステップＳ７４：Ｎｏ）、負荷計測部８１５は、負荷計測を終了する（ステップＳ７５）。
【０１２１】
図１３Ｃは、第２の実施形態による異常診断装置８の送信側端末８１の動作の変形例を示すフローチャートである。図１３Ｃのフローチャートは、必要に応じて繰り返される。ＣＰＵの使用率または伝送負荷率が許容値を超える場合、図１３Ｃに示すように、転送・診断部８１２は、一次異常診断のうちのヘッダ情報判定処理を省略してもよい。
【０１２２】
図１３Ｄは、第２の実施形態による異常診断システム１のクラウド診断装置３の動作例を示すフローチャートである。第２の実施形態において、クラウド診断装置３による異常診断は、図１３Ｄのフローチャートにしたがって実施される。図１３Ｄのフローチャートは、必要に応じて繰り返される。
【０１２３】
具体的には、図９Ａで説明した新規の診断データの受信の有無の判定において、新規の診断データが受信された場合（ステップＳ６２：Ｙｅｓ）、診断切替部３５は、診断モード切替信号が受信されたか否かを判定する（ステップＳ６４）。
【０１２４】
診断モード切替信号が受信された場合（ステップＳ６４：Ｙｅｓ）、診断切替部３５は、二次異常診断に加えて制御システム２側で省略されたヘッダ情報判定処理を実施するように診断部３２の診断モードを切り替える。これにより、診断部３２は、ＤＰＩ判定処理（ステップＳ６３）に加えてヘッダ情報判定処理（ステップＳ４）を実施する。
【０１２５】
一方、診断モード切替信号が受信されていない場合（ステップＳ６４：Ｎｏ）、診断切替部３５は、診断モードを切り替えず、診断部３２は、ＤＰＩ判定処理（ステップＳ６３）のみを実施する。
【０１２６】
第２の実施形態によれば、運用環境の変化等によって異常診断装置８にかかる負荷が増大した場合でも、動的に一次異常診断をクラウド側で分担できるため、診断機能を維持して可用性を向上させることができる。
【０１２７】
（第３の実施形態）
次に、学習モードと診断モードとを選択可能な第３の実施形態について説明する。
【０１２８】
図１４Ａは、第３の実施形態による異常診断装置８を示すブロック図である。
【０１２９】
第３の実施形態において、送信側端末８１は、第１の実施形態の構成に加えて、更に、第１モード切替部８１６を有する。
【０１３０】
第１モード切替部８１６は、転送・診断部８１２の動作モードを、診断モードと学習モードとの間で切り替える。
【０１３１】
転送・診断部８１２は、診断モードでは、第１判定テーブルに基づいて一次異常診断を実施する。一方、転送・診断部８１２は、学習モードでは、送信側端末８１に入力された第１判定テーブルを第１判定テーブル保存部８１３に登録する。
【０１３２】
図１４Ｂは、第３の実施形態によるクラウド診断装置３を示すブロック図である。
【０１３３】
第３の実施形態において、クラウド診断装置３は、第１の実施形態の構成に加えて、更に、第２モード切替部３７と、表示部３６とを有する。
【０１３４】
第２モード切替部３７は、診断部３２の動作モードを、診断モードと学習モードとの間で切り替える。
【０１３５】
診断部３２は、診断モードでは、第２判定テーブルに基づいて二次異常診断を実施する。一方、診断部３２は、学習モードでは、受信された診断データに基づいて第２判定テーブルを第２判定テーブル保存部３３に登録する。
【０１３６】
図１５Ａは、第３の実施形態による異常診断装置８の送信側端末８１の動作例を示すフローチャートである。第３の実施形態による異常診断システム１のうち、異常診断装置８の送信側端末８１は、図１５Ａのフローチャートにしたがって動作する。図１５Ａのフローチャートは、必要に応じて繰り返される。
【０１３７】
図１５Ａのフローチャートは、図３Ａのフローチャートに対しして、学習モードを実行するための工程（ステップＳ８１〜ステップＳ８５）が追加されている点で異なり、他の点で同様である。以下の説明では、図３Ａと異なる工程についてのみ詳細に説明する。
【０１３８】
先ず、転送・診断部８１２は、転送・診断部８１２の動作モードが学習モードであるか否かを判定する（ステップＳ８１）。
【０１３９】
学習モードでない場合（ステップＳ８１：Ｎｏ）、転送・診断部８１２は、図３Ａで説明した診断工程を実行する（ステップＳ１〜ステップＳ５）。
【０１４０】
一方、学習モードである場合（ステップＳ８１：Ｙｅｓ）、転送・診断部８１２は、学習処理を開始する（ステップＳ８２）。
【０１４１】
学習処理を開始した後、転送・診断部８１２は、新規の診断データが受信されたか否かを判定する（ステップＳ８３）。ただし、このとき受信される診断データは、診断には用いられずに第１判定テーブルの作成に用いられる。
【０１４２】
新規の診断データが受信された場合（ステップＳ８３：Ｙｅｓ）、転送・診断部８１２は、受信された診断データに含まれる送信元ＩＰアドレスおよび送信先ＩＰアドレスが、第１判定テーブル保存部８１３に登録済みであるか否かを判定する（ステップＳ８４）。
【０１４３】
送信元ＩＰアドレスおよび送信先ＩＰアドレスが登録済みでない場合（ステップＳ８４：Ｎｏ）、転送・診断部８１２は、受信された診断データに含まれる送信元ＩＰアドレスおよび送信先ＩＰアドレスを、第１判定テーブルとして第１判定テーブル保存部８１３に登録する（ステップＳ８５）。
【０１４４】
一方、送信元ＩＰアドレスおよび送信先ＩＰアドレスが登録済みの場合（ステップＳ８４：Ｙｅｓ）、転送・診断部８１２は、学習モードであるか否かの判定を繰り返す（ステップＳ８１）。
【０１４５】
このようにして、新たな診断データの受信に応じて未登録の送信元ＩＰアドレスおよび送信先ＩＰアドレスを第１判定テーブル保存部８１３に逐次登録することで、第１判定テーブルを作成する。
【０１４６】
学習モードによって第１判定テーブルを作成した後は、第１モード切替部８１６によって転送・診断部８１２の動作モードを診断モードに切り替え、転送・診断部８１２によって第１判定テーブルを用いた第１の異常診断を実施する。学習モードから診断モードへの切り替えは、例えば電源投入後一定時間後に自動で実行してもよく、または、ユーザ操作に応じた任意のタイミングで実行してもよい。
【０１４７】
図１５Ｂは、第３の実施形態による異常診断システム１のクラウド診断装置３の動作例を示すフローチャートである。第３の実施形態による異常診断システム１のうち、クラウド診断装置３は、図１５Ｂのフローチャートにしたがって動作する。図１５Ｂのフローチャートは、必要に応じて繰り返される。
【０１４８】
図１５Ｂのフローチャートは、図９Ａのフローチャートに対しして、学習モードを実行するための工程（ステップＳ９１〜ステップＳ９５）が追加されている点で異なり、他の点で同様である。以下の説明では、図９Ａと異なる工程についてのみ詳細に説明する。
【０１４９】
先ず、診断部３２は、診断部３２の動作モードが学習モードであるか否かを判定する（ステップＳ９１）。
【０１５０】
学習モードでない場合（ステップＳ９１：Ｎｏ）、診断部３２は、図９Ａで説明した診断工程を実行する（ステップＳ６１〜ステップＳ６３）。
【０１５１】
一方、学習モードである場合（ステップＳ９１：Ｙｅｓ）、診断部３２は、学習処理を開始する（ステップＳ９２）。
【０１５２】
学習処理を開始した後、診断部３２は、新規の診断データが受信されたか否かを判定する（ステップＳ９３）。ただし、このとき受信される診断データは、診断には用いられずに第２判定テーブルの作成に用いられる。
【０１５３】
新規の診断データが受信された場合（ステップＳ９３：Ｙｅｓ）、診断部３２は、受信された診断データのフィールド毎に、制御値の最小値および最大値の更新の要否を判定する（ステップＳ９４）。要否の判定は、制御値が既登録か否かの判定であってもよい。
【０１５４】
制御値の最小値および最大値の更新が必要である場合、（ステップＳ９４：Ｙｅｓ）、診断部３２は、制御値の最小値および最大値を、第２判定テーブルとして第２判定テーブル保存部３３に登録する（ステップＳ９５）。
【０１５５】
一方、制御値の最小値および最大値の更新が不要である場合（ステップＳ９４：Ｙｅｓ）、診断部３２は、学習モードであるか否かの判定を繰り返す（ステップＳ９１）。
【０１５６】
第３の実施形態によれば、ユーザが手動で判定テーブルを作成する必要がなくなるため、利便性を向上させることができる。
【０１５７】
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれると同様に、特許請求の範囲に記載された発明とその均等の範囲に含まれるものである。
【符号の説明】
【０１５８】
１  異常診断システム、２  制御システム、８  異常診断装置、８１  送信側端末、８２  受信側端末
【図１】
2019213058.tif 000003
【図２Ａ】
2019213058.tif 000004
【図２Ｂ】
2019213058.tif 000005
【図３Ａ】
2019213058.tif 000006
【図３Ｂ】
2019213058.tif 000007
【図４】
2019213058.tif 000008
【図５】
2019213058.tif 000009
【図６Ａ】
2019213058.tif 000010
【図６Ｂ】
2019213058.tif 000011
【図７】
2019213058.tif 000012
【図８】
2019213058.tif 000013
【図９Ａ】
2019213058.tif 000014
【図９Ｂ】
2019213058.tif 000015
【図１０】
2019213058.tif 000016
【図１１】
2019213058.tif 000017
【図１２Ａ】
2019213058.tif 000018
【図１２Ｂ】
2019213058.tif 000019
【図１３Ａ】
2019213058.tif 000020
【図１３Ｂ】
2019213058.tif 000021
【図１３Ｃ】
2019213058.tif 000022
【図１３Ｄ】
2019213058.tif 000023
【図１４Ａ】
2019213058.tif 000024
【図１４Ｂ】
2019213058.tif 000025
【図１５Ａ】
2019213058.tif 000026
【図１５Ｂ】
2019213058.tif 000027