特許 7186518 異常診断装置、異常診断システムおよび異常診断方法

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

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

(11)【特許番号】

(24)【登録日】2022-12-01

(45)【発行日】2022-12-09

(54)【発明の名称】異常診断装置、異常診断システムおよび異常診断方法

(51)【国際特許分類】

   H04L 43/08 20220101AFI20221202BHJP

   H04L 12/66 20060101ALI20221202BHJP

   H04L 12/22 20060101ALI20221202BHJP

   G05B 23/02 20060101ALI20221202BHJP

【ＦＩ】

H04L43/08

H04L12/66

H04L12/22

G05B23/02 302Z

【請求項の数】 8

(21)【出願番号】P 2018107825

(22)【出願日】2018-06-05

(65)【公開番号】P2019213058

(43)【公開日】2019-12-12

【審査請求日】2021-02-08

(73)【特許権者】

【識別番号】000003078

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

(73)【特許権者】

【識別番号】317015294

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

(74)【代理人】

【識別番号】100091982

【弁理士】

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

(74)【代理人】

【識別番号】100091487

【弁理士】

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

(74)【代理人】

【識別番号】100082991

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

(74)【代理人】

【識別番号】100105153

【弁理士】

【氏名又は名称】朝倉 悟

(74)【代理人】

【識別番号】100107582

【弁理士】

【氏名又は名称】関根 毅

(74)【代理人】

【識別番号】100124372

【弁理士】

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

(74)【代理人】

【識別番号】100120385

【弁理士】

【氏名又は名称】鈴木 健之

(72)【発明者】

【氏名】丸地 俊也

(72)【発明者】

【氏名】三宅 秀享

(72)【発明者】

【氏名】天木 智

(72)【発明者】

【氏名】中谷 博司

【審査官】岩田 玲彦

(56)【参考文献】

【文献】特開２０１２－０９４０４４（ＪＰ，Ａ）

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

【文献】特開２００６－１９１４３３（ＪＰ，Ａ）

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

Ｇ０５Ｂ ２３／０２

Ｈ０４Ｌ １２／２２

１２／６６

４３／００－４３／５５

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

【請求項1】

ネットワークを介したデータ通信により機器を制御する制御システム内に設けられ、前記制御システムの異常を診断する異常診断装置であって、
前記異常診断装置は、送信側端末と、受信側端末とを備え、前記データ通信で用いられるネットワークデータに相当する内容の診断データを、前記送信側端末と前記受信側端末との間で、前記送信側端末から前記受信側端末に向かう方向および前記受信側端末から前記送信側端末に向かう方向のうちの、前記送信側端末から前記受信側端末に向かう一方向にのみ送信し、
前記送信側端末は、前記制御システム内の前記送信側端末以外の装置から前記診断データを取得し、前記取得された診断データを前記一方向に送信し、かつ、前記取得された診断データに基づいて前記制御システムに対する一次異常診断を実施して診断結果を前記制御システム内に出力し、
前記受信側端末は、前記送信側端末から送信された前記診断データを受信し、前記受信された診断データを前記制御システムに対する二次異常診断を実施する外部診断装置に送信する、異常診断装置。

【請求項2】

前記送信側端末は、第１通信インタフェース部と、転送・診断部と、判定テーブル保存部と、第２通信インタフェース部と、を有し、
前記受信側端末は、第３通信インタフェース部と、転送部と、第４通信インタフェース部と、を有し、
前記第１通信インタフェース部は、前記制御システム内のネットワークスイッチから出力された前記診断データを取得し、取得された前記診断データを前記転送・診断部に出力し、
前記転送・診断部は、前記第１通信インタフェース部から出力された前記診断データを前記第２通信インタフェース部に転送し、かつ、前記診断データに基づいて前記一次異常診断を実施して診断結果を前記制御システム内に出力し、
前記判定テーブル保存部は、前記一次異常診断における異常の有無の判定に用いられる判定テーブルを保存し、
前記第２通信インタフェース部は、前記転送・診断部から転送された前記診断データを前記第３通信インタフェース部に向けて前記一方向に出力し、
前記第３通信インタフェース部は、前記第２通信インタフェース部から出力された前記診断データを前記一方向から入力し、入力された前記診断データを前記転送部に出力し、
前記転送部は、前記第３通信インタフェース部から出力された前記診断データを第４通信インタフェース部に転送し、
前記第４通信インタフェース部は、前記転送部から転送された前記診断データを入力して前記外部診断装置に出力する、請求項１に記載の異常診断装置。

【請求項3】

前記送信側端末は、前記送信側端末の負荷を計測する負荷計測部を更に備え、
前記転送・診断部は、前記負荷計測部で計測された前記負荷が許容値を超えた場合には、前記一次異常診断のうちの少なくとも一部の診断を省略し、前記省略された診断を指示する診断指示信号を前記受信側端末に送信し、
前記受信側端末は、前記診断指示信号を受信して前記外部診断装置に送信する、請求項２に記載の異常診断装置。

【請求項4】

前記送信側端末は、前記転送・診断部の動作モードを診断モードと学習モードとの間で切り替えるモード切替部を更に備え、
前記転送・診断部は、前記診断モードでは、前記判定テーブルに基づいて前記一次異常診断を実施し、前記学習モードでは、前記送信側端末に入力された診断データに含まれる送信元ＩＰアドレスおよび送信先ＩＰアドレスを前記判定テーブルとして前記判定テーブル保存部に登録する、請求項２に記載の異常診断装置。

【請求項5】

前記一次異常診断は、前記制御システムがセキュリティ異常を有するか否かの診断を含み、
前記判定テーブル保存部は、前記判定テーブルとして前記ネットワークデータのパケットのヘッダ情報を保存し、
前記転送・診断部は、前記診断データが前記判定テーブル保存部に保存された前記ヘッダ情報を有しない場合に、前記制御システムが前記セキュリティ異常を有する旨の診断結果を出力する、請求項２に記載の異常診断装置。

【請求項6】

前記一次異常診断は、前記制御システムがセキュリティ攻撃を受けているか否かの診断を含み、
前記転送・診断部は、規定時間内の前記診断データの受信パケット数を解析し、前記受信パケット数が規定数を超えた場合に、前記制御システムがセキュリティ攻撃を受けている旨の診断結果を出力する、請求項２に記載の異常診断装置。

【請求項7】

ネットワークを介したデータ通信により機器を制御する制御システム内に設けられ、前記制御システムの異常を診断する異常診断装置と、
前記制御システムの外部に設けられた外部診断装置と、を備え、
前記異常診断装置は、送信側端末と、受信側端末とを備え、前記データ通信で用いられるネットワークデータに相当する内容の診断データを、前記送信側端末と前記受信側端末との間で、前記送信側端末から前記受信側端末に向かう方向および前記受信側端末から前記送信側端末に向かう方向のうちの、前記送信側端末から前記受信側端末に向かう一方向にのみ送信し、
前記送信側端末は、前記制御システム内の前記送信側端末以外の装置から前記診断データを取得し、前記取得された診断データを前記一方向に送信し、かつ、前記取得された診断データに基づいて前記制御システムに対する一次異常診断を実施して診断結果を前記制御システム内に出力し、
前記受信側端末は、前記送信側端末から送信された前記診断データを受信し、前記受信された診断データを前記外部診断装置に送信し、
前記外部診断装置は、
前記受信側端末から送信された前記診断データに基づいて、前記制御システムに対する二次異常診断を実施して診断結果を前記制御システムに接続されていないユーザ端末に送信する、異常診断システム。

【請求項8】

異常診断装置が、ネットワークを介したデータ通信により機器を制御する制御システムの異常を診断する異常診断方法であって、
前記異常診断装置は、送信側端末と、受信側端末とを備え、前記データ通信で用いられるネットワークデータに相当する内容の診断データを、前記送信側端末と前記受信側端末との間で、前記送信側端末から前記受信側端末に向かう方向および前記受信側端末から前記送信側端末に向かう方向のうちの、前記送信側端末から前記受信側端末に向かう一方向にのみ送信し、
前記送信側端末が、前記診断データを前記制御システム内において前記送信側端末以外の装置から取得し、
前記送信側端末が、前記取得された診断データを前記制御システム内において前記一方向に送信し、かつ、前記取得された診断データに基づいて前記制御システムに対する一次異常診断を実施して診断結果を前記制御システム内に出力し、
前記受信側端末が、前記一方向に送信された前記診断データを前記制御システム内において受信し、前記受信された診断データを前記制御システムに対する二次異常診断を実施する外部診断装置に送信する、異常診断方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明による実施形態は、異常診断装置、異常診断システムおよび異常診断方法に関する。

【背景技術】

【0002】

プラント等に設置された機器を制御する制御システムでは、近年、オープンネットワーク化が進んでいる。このような制御システムでは、ネットワークのセキュリティ対策が重要になる。

【0003】

ネットワークのセキュリティを確保するための技術として、クラウド上のリモート監視端末に向けて一方向にのみデータを送信可能なデータダイオードと呼ばれる装置が知られている。また、データダイオードの他にも、ネットワークの情報からセキュリティに関する異常を検知するＩＤＳ（Ｉｎｔｒｕｓｉｏｎ Ｄｅｔｅｃｔｉｏｎ Ｓｙｓｔｅｍ）と呼ばれる装置が知られている。

【0004】

しかしながら、データダイオードを制御システムに適用した場合、データは現場（制御システム）側からクラウド側に向けて一方向にのみ送信されるため、クラウド側で異常を検知しても現場側に異常を通知することができないといった問題がある。

【0005】

また、ＩＤＳを制御システムに適用した場合、制御システムの制御周期内に異常の検知処理が完了しない場合に、データが逐次蓄積されていくため、すべてのデータが検知処理に必要な場合、データの増加により検知が遅れてしまうといった問題がある。

【先行技術文献】

【特許文献】

【0006】

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

【発明の概要】

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

【0007】

本発明は上述した点を考慮してなされたものであり、セキュリティを確保しながら制御システムの異常を制御システム側に迅速に通知することができる異常診断装置、異常診断システムおよび異常診断方法を提供することを目的とする。

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

【0008】

本実施形態による異常診断装置は、
ネットワークを介したデータ通信により機器を制御する制御システム内に設けられ、前記制御システムの異常を診断する異常診断装置であって、
前記データ通信で用いられるネットワークデータとして診断データを取得し、前記取得された診断データを一方向にのみ送信し、かつ、前記取得された診断データに基づいて前記制御システムに対する一次異常診断を実施して診断結果を前記制御システム内に出力する送信側端末と、
前記送信側端末から送信された前記診断データを受信し、前記受信された診断データを前記制御システムに対する二次異常診断を実施する外部診断装置に送信する受信側端末と、を備える。

【発明の効果】

【0009】

本発明によれば、セキュリティを確保しながら制御システムの異常を制御システム側に迅速に通知することができる。

【図面の簡単な説明】

【0010】

【図1】第１の実施形態による異常診断システムを示すブロック図である。

【図2A】第１の実施形態による異常診断装置を示すブロック図である。

【図2B】第１の実施形態によるクラウド診断装置を示すブロック図である。

【図3A】第１の実施形態による異常診断装置の送信側端末の動作例を示すフローチャートである。

【図3B】第１の実施形態による異常診断装置の受信側端末の動作例を示すフローチャートである。

【図4】第１の実施形態による異常診断装置の動作例において、第１判定テーブルを示す図である。

【図5】第１の実施形態による異常診断装置の送信側端末の動作例において、ヘッダ情報判定処理を示すフローチャートである。

【図6A】第１の実施形態による異常診断装置の動作例において、不正端末の接続による異常の通知画面を示す図である。

【図6B】第１の実施形態による異常診断装置の動作例において、端末の不正利用による異常の通知画面を示す図である。

【図7】第１の実施形態による異常診断装置の送信側端末の動作例において、統計情報判定処理を示すフローチャートである。

【図8】第１の実施形態による異常診断装置の動作例において、不正攻撃による異常の通知画面を示す図である。

【図9A】第１の実施形態による異常診断システムのクラウド診断装置の動作例を示すフローチャートである。

【図9B】第１の実施形態による異常診断システムのクラウド診断装置の動作例において、ＤＰＩ判定処理を示すフローチャートである。

【図10】第１の実施形態による異常診断システムのクラウド診断装置の動作例において、ＤＰＩ判定処理に用いられる第２判定テーブルを示す図である。

【図11】第１の実施形態による異常診断システムのクラウド診断装置の動作例において、ＤＰＩ判定処理の変形例を示すフローチャートである。

【図12A】第２の実施形態による異常診断装置を示すブロック図である。

【図12B】第２の実施形態によるクラウド診断装置を示すブロック図である。

【図13A】第２の実施形態による異常診断装置の送信側端末の動作例を示すフローチャートである。

【図13B】第２の実施形態による異常診断装置の送信側端末の動作例において、負荷計測を示すフローチャートである。

【図13C】第２の実施形態による異常診断装置の送信側端末の動作の変形例を示すフローチャートである。

【図13D】第２の実施形態による異常診断システムのクラウド診断装置の動作例を示すフローチャートである。

【図14A】第３の実施形態による異常診断装置を示すブロック図である。

【図14B】第３の実施形態によるクラウド診断装置を示すブロック図である。

【図15A】第３の実施形態による異常診断システムの送信側端末の動作例を示すフローチャートである。

【図15B】第３の実施形態による異常診断システムのクラウド診断装置の動作例を示すフローチャートである。

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

【0011】

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

【0012】

（第１の実施形態）
図１は、第１の実施形態による異常診断システム１を示すブロック図である。第１の実施形態による異常診断システム１は、例えば、プラントやＦＡ(Factory Automation)等に設置された機器を制御するシステムの異常を診断するために用いることができる。

【0013】

図１に示すように、異常診断システム１は、制御システム２と、外部診断装置の一例であるクラウド診断装置３と、を備える。

【0014】

制御システム２は、ネットワークを介したデータ通信により機器を制御する。ネットワークは、例えば、Ｅｔｈｅｒｎｅｔ（登録商標）であってもよいが、これに限定されない。

【0015】

機器を制御するための具体的な構成として、図１に示すように、制御システム２は、複数の制御装置４（Ａ～Ｃ）と、ＨＭＩ(Human Machine Interface)５と、ツール６と、ネットワークスイッチ（ＳＷ）７と、異常診断装置８と、を有する。

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

ｉ番目の送信元ＩＰアドレスおよび送信先ＩＰアドレスを探索した後、転送・診断部８１２は、新規の診断データの送信元ＩＰアドレスおよび送信先ＩＰアドレスと、ｉ番目の送信元ＩＰアドレスおよび送信先ＩＰアドレスとを比較し、両者が一致するか否かを判定する（ステップＳ４３）。

【0061】

新規の診断データの送信元ＩＰアドレスおよび送信先ＩＰアドレスと、ｉ番目の送信元ＩＰアドレスおよび送信先ＩＰアドレスとが一致する場合（ステップＳ４３：Ｙｅｓ）、転送・診断部８１２は、制御システム２が正常であると判定する（ステップＳ４４）。

【0062】

一方、新規の診断データの送信元ＩＰアドレスおよび送信先ＩＰアドレスと、ｉ番目の送信元ＩＰアドレスおよび送信先ＩＰアドレスとが一致しない場合（ステップＳ４３：Ｎｏ）、転送・診断部８１２は、新規の診断データの送信元ＩＰアドレスと、ｉ番目の送信元ＩＰアドレスとが一致するか否かを判定する（ステップＳ４５）。

【0063】

新規の診断データの送信元ＩＰアドレスとｉ番目の送信元ＩＰアドレスとが一致する場合（ステップＳ４５：Ｙｅｓ）、転送・診断部８１２は、フラグＦＬＧの値を「１」にセットする（ステップＳ４６）。

【0064】

フラグＦＬＧの値を「１」にセットした後、または、新規の診断データの送信元ＩＰアドレスとｉ番目の送信元ＩＰアドレスとが一致しない場合（ステップＳ４５：Ｎｏ）、転送・診断部８１２は、第１判定テーブルの全行のＩＰアドレスの探索が終了したか否かを判定する（ステップＳ４７）。

【0065】

第１判定テーブルの全行のＩＰアドレスの探索が終了した場合（ステップＳ４７：Ｙｅｓ）、転送・診断部８１２は、フラグＦＬＧが「１」にセットされているか否かを判定する（ステップＳ４８）。

【0066】

一方、第１判定テーブルの全行のＩＰアドレスの探索が終了していない場合（ステップＳ４７：Ｎｏ）、転送・診断部８１２は、ｉをインクリメントして第１判定テーブル内の次行のＩＰアドレスの探索に移行する（ステップＳ４９）。

【0067】

フラグＦＬＧが「１」にセットされていない場合（ステップＳ４８：Ｎｏ）、送信元ＩＰアドレスが第１判定テーブル保存部８１３に保存されていないことになる。この場合、転送・診断部８１２は、制御システム２が異常である、すなわち、不正な端末がネットワークに接続されたと判定する（ステップＳ４１０）。

【0068】

不正な端末がネットワークに接続されたと判定した後、転送・診断部８１２は、その旨をユーザに通知する（ステップＳ４１１）。

【0069】

図６Ａは、第１の実施形態による異常診断装置８の動作例において、不正端末の接続による異常の通知画面を示す図である。例えば、転送・診断部８１２は、図６Ａの通知画面をＨＭＩ５の表示部に表示することで、不正な端末がネットワークに接続された旨をユーザに通知する。

【0070】

不正な端末がネットワークに接続された旨をユーザに通知した後、転送・診断部８１２は、フラグＦＬＧを「０」にセット（ステップＳ４１２）したうえで、ヘッダ情報判定処理を終了する（ステップＳ４１３）。

【0071】

一方、フラグＦＬＧが「１」にセットされている場合（ステップＳ４８：Ｙｅｓ）、送信先ＩＰアドレスは第１判定テーブルに存在しないが、送信元ＩＰアドレスは第１判定テーブルに存在していることになる。この場合、転送・診断部８１２は、制御システム２が異常である、すなわち、端末が不正に操作され、情報が漏洩していると判定する（ステップＳ４１４）。

【0072】

端末が不正に操作され、情報が漏洩していると判定した後、転送・診断部８１２は、その旨をユーザに通知する（ステップＳ４１５）。

【0073】

図６Ｂは、第１の実施形態による異常診断装置８の動作例において、端末の不正利用による異常の通知画面を示す図である。例えば、転送・診断部８１２は、図６Ｂの通知画面をＨＭＩ５の表示部に表示することで、端末が不正に操作され、情報が漏洩している旨をユーザに通知する。

【0074】

なお、ＩＰアドレスを用いたヘッダ情報判定処理について説明したが、ヘッダ情報判定処理には、ＩＰアドレスに加えて、または、ＩＰアドレスに代えて、診断データのＭＡＣアドレス、送信回数、頻度などを用いることもできる。また、セキュリティの判定をより厳密化するため、送信元ＩＰアドレスおよび送信先ＩＰアドレスに加え、プロトコル情報を加味してもよい。この場合、例えば、第１判定テーブルに保存されたプロトコル情報がＴＣＰやＵＤＰであるのに対して、新規の診断データのプロトコルがＳＳＨである場合には、不正な端末がネットワークに接続されたと判定してもよい。これにより送信元ＩＰアドレスおよび送信先ＩＰアドレスが同一でも、不正なプロトコルでアクセスを試みているケースが抽出可能になる。

【0075】

ヘッダ情報判定処理を終了した後、図３Ａに示すように、転送・診断部８１２は、受信された新規の診断データに基づいて、一次異常診断処理のうちの統計情報判定処理を実行する（ステップＳ５）。

【0076】

図７は、第１の実施形態による異常診断装置８の送信側端末８１の動作例において、統計情報判定処理を示すフローチャートである。統計情報判定処理は、図７のフローチャートにしたがって行われる。

【0077】

具体的には、先ず、転送・診断部８１２は、統計情報判定処理を開始した後（ステップＳ５１）、新規の診断データの受信に応じてインクリメントされるカウンタ変数およびタイマの計測時間を初期化（ｉ＝０、timer＝０）する（ステップＳ５２）。

【0078】

カウンタ変数を初期化した後、転送・診断部８１２は、新規の診断データを受信する（ステップＳ５３）。

【0079】

新規の診断データを受信した後、転送・診断部８１２は、カウンタ変数をインクリメント（ｉ++）する（ステップＳ５４）。

【0080】

カウンタ変数をインクリメントした後、転送・診断部８１２は、カウンタ変数が規定数ｉ＿ｔｈを超えたか否かを判定する（ステップＳ５５）。規定数ｉ＿ｔｈは予め決めておいてもよいし、動的にユーザが変更可能なものでもよい。

【0081】

カウンタ変数が規定数ｉ＿ｔｈを超えた場合（ステップＳ５５：Ｙｅｓ）、転送・診断部８１２は、制御システム２が異常であると判定する（ステップＳ５６）。より詳しくは、転送・診断部８１２は、制御システム２がＤｏＳ攻撃などのサービス不能攻撃を受信していると判定する。

【0082】

図８は、第１の実施形態による異常診断装置８の動作例において、不正攻撃による異常の通知画面を示す図である。例えば、転送・診断部８１２は、図８の通知画面をＨＭＩ５の表示部に表示することで、サービス不能攻撃を受けている旨をユーザに通知する。

【0083】

カウンタ変数が規定数ｉ＿ｔｈを超えていない場合（ステップＳ５５：Ｎｏ）、転送・診断部８１２は、タイマの計測時間が規定時間ｔｉｍｅ＿ｔｈを超えたか否かを判定する（ステップＳ５７）。

【0084】

タイマの計測時間が規定時間ｔｉｍｅ＿ｔｈを超えた場合（ステップＳ５７：Ｙｅｓ）、転送・診断部８１２は、タイマの計測時間とカウンタ変数とをクリアしたうえで新規の診断データの受信に遷移する（ステップＳ５３）。

【0085】

一方、タイマの計測時間が規定時間ｔｉｍｅ＿ｔｈを超えていない場合（ステップＳ５７：Ｎｏ）、転送・診断部８１２は、制御システム２が正常であると判定して統計情報判定処理を終了する（ステップＳ５８）。

【0086】

図３Ｂは、第１の実施形態による異常診断装置８の受信側端末８２の動作例を示すフローチャートである。第１の実施形態による異常診断システム１のうち、異常診断装置８の受信側端末８２は、図３Ｂのフローチャートにしたがって動作する。図３Ｂのフローチャートは、必要に応じて繰り返される。

【0087】

具体的には、先ず、転送部８２２は、診断データの転送処理を開始した後（ステップＳ１１）、新規の診断データが受信されたか否かを判定する（ステップＳ１２）。

【0088】

新規の診断データが受信された場合（ステップＳ１２：Ｙｅｓ）、転送部８２２は、第３通信インタフェース部８２１で受信された新規の診断データを、第４通信インタフェース部８２３を介してクラウド診断装置３に転送する（ステップＳ１３）。

【0089】

一方、新規の診断データが受信されていない場合（ステップＳ１２：Ｎｏ）、転送部８２２は、新規の診断データが受信されたか否かの判定を繰り返す（ステップＳ１２）。

【0090】

図９Ａは、第１の実施形態による異常診断システム１のクラウド診断装置３の動作例を示すフローチャートである。第１の実施形態による異常診断システム１のうち、クラウド診断装置３は、図９Ａのフローチャートにしたがって動作する。図９Ａのフローチャートは、必要に応じて繰り返される。

【0091】

具体的には、先ず、診断部３２は、二次異常診断処理を開始した後（ステップＳ６１）、新規の診断データが受信されたか否かを判定する（ステップＳ６２）。

【0092】

新規の診断データが受信された場合（ステップＳ６２：Ｙｅｓ）、診断部３２は、第５通信インタフェース部３１で受信された新規の診断データに基づいて、二次異常診断処理としてＤＰＩ(Deep Packet Inspection)判定処理を行う（ステップＳ６３）。なお、二次異常診断処理は、更に、既述した統計情報判定処理を含んでもよい。

【0093】

図９Ｂは、第１の実施形態による異常診断システム１のクラウド診断装置３の動作例において、ＤＰＩ判定処理を示すフローチャートである。図１０は、第１の実施形態による異常診断システム１のクラウド診断装置３の動作例において、ＤＰＩ判定処理に用いられる第２判定テーブルを示す図である。図１０の第２判定テーブルは、ネットワークデータのペイロード部を構成するフィールド（Ｎｏ１～）毎に、制御値の最小値および最大値と、周期的に値が増加する時刻データの前回値が格納されている。時刻データは、制御システム２の健全性の確認に用いることができる。ＤＰＩ判定処理は、図１０の第２判定テーブルを用いて図９Ｂのフローチャートにしたがって実行される。

【0094】

具体的には、診断部３２は、ＤＰＩ判定処理を開始した後（ステップＳ６３１）、第２判定テーブルの中からｉ番目のフィールドを探索する（ステップＳ６３２）。なお、ｉの初期値は１である。

【0095】

第２の判定テーブルからｉ番目のフィールドを探索した後、診断部３２は、探索されたｉ番目のフィールドに基づいて、新規の診断データのｉ番目のフィールドが正常であるか否かを判定する（ステップＳ６３３）。

【0096】

例えば、診断部３２は、新規の診断データのｉ番目のフィールドの制御値が、第２判定テーブルのｉ番目のフィールドの制御値の最小値と最大値との間の範囲内であるか否かを判定する。また、診断部３２は、新規の診断データのｉ番目のフィールドの時刻データが、第２判定テーブルのｉ番目のフィールドの前回値から更新されているか否かを判定する。そして、新規の診断データの制御値が最小値と最大値との間の範囲内であり、かつ、新規の診断データの時刻データ（すなわち、健全性確認データ）が前回値から更新されている場合に、制御システム２が正常であると判定し、そうでない場合に、制御システム２が異常であると判定する。

【0097】

新規の診断データのｉ番目のフィールドが正常である場合（ステップＳ６３３：Ｙｅｓ）、診断部３２は、全てのフィールドの探索が終了したか否かを判定する（ステップＳ６３４）。

【0098】

一方、新規の診断データのｉ番目のフィールドが異常である場合（ステップＳ６３３：Ｎｏ）、診断部３２は、制御システム２が異常であると判定する（ステップＳ６３５）。この場合、診断部３２は、携帯回線等の異常診断システム１の通信回線以外の通信回線を用いて、ユーザ端末９に制御システム２の異常を通知する。

【0099】

全てのフィールドの探索が終了した場合（ステップＳ６３４：Ｙｅｓ）、診断部３２は、制御システム２が正常であると判定してＤＰＩ判定処理を終了する（ステップＳ６３６）。

【0100】

一方、全てのフィールドの探索が終了していない場合（ステップＳ６３４：Ｎｏ）、診断部３２は、ｉをインクリメントして次のフィールドの探索に遷移する（ステップＳ６３７）。

【0101】

図１１は、第１の実施形態による異常診断システム１のクラウド診断装置３の動作例において、ＤＰＩ判定処理の変形例を示すフローチャートである。診断データが共通鍵で暗号化されている場合、図１１に示すように、診断部３２は、ＤＰＩ判定処理を開始した後（ステップＳ６３１）、制御システム２内の共通鍵から復号化アルゴリズムを適用して復号処理（ステップＳ６３８）を行えばよい。そして、復号化された診断データに基づいて、ＤＰＩ判定処理を実行すればよい。診断データの暗号化方式については、共通鍵方式のものであればアルゴリズムは問わない。

【0102】

第１の実施形態によれば、セキュリティが確保された分散型アーキテクチャを構築でき、制御システム２の伝送パケットの一次異常診断を現場側で実施し、詳細な二次異常診断をクラウド側で実施することができる。これにより、セキュリティを確保しつつ、現場側の診断結果については制御システム２へ直接通知が可能になり、詳細な診断結果はユーザへ通知することが可能になる。すなわち、第１の実施形態によれば、セキュリティを確保しながら制御システム２の異常を制御システム２側に迅速に通知することができる。

【0103】

（第２の実施形態）
次に、送信側端末８１の負荷に応じて一次異常診断をクラウド側で分担する第２の実施形態について説明する。

【0104】

図１２Ａは、第２の実施形態による異常診断装置８を示すブロック図である。

【0105】

第２の実施形態において、送信側端末８１は、第１の実施形態の構成に加えて、更に、負荷計測部８１５を有する。負荷計測部８１５は、送信側端末８１の負荷を計測する。

【0106】

送信側端末８１の転送部８２２は、負荷計測部８１５で計測された負荷が許容値を超えた場合には、一次異常診断のうちの少なくとも一部の診断を省略する。そして、転送・診断部８１２は、省略された診断をクラウド診断装置３の診断部３２に指示するため、診断指示信号の一例である診断モード切替信号を受信側端末８２に送信する。

【0107】

受信側端末８２の転送部８２２は、送信側端末８１の転送・診断部８１２から送信された診断モード切替信号を受信してクラウド診断装置３に送信する。

【0108】

図１２Ｂは、第２の実施形態によるクラウド診断装置３を示すブロック図である。

【0109】

第２の実施形態において、クラウド診断装置３は、第１の実施形態の構成に加えて、更に、診断切替部３５と、表示部３６とを有する。

【0110】

診断切替部３５は、転送部８２２から送信された診断モード切替信号に応じて、二次異常診断に加えて転送・診断部８１２で省略された一次異常診断の診断項目も診断するように診断部３２の診断モードを切り替える。

【0111】

表示部３６は、診断部３２で判定された制御システム２の異常状態や、トレンド情報を表示する。

【0112】

（動作例）
次に、以上のように構成された第２の実施形態による異常診断システム１の動作例について説明する。

【0113】

図１３Ａは、第２の実施形態による異常診断装置８の送信側端末８１の動作例を示すフローチャートである。第２の実施形態による異常診断システム１のうち、異常診断装置８の送信側端末８１は、図１３Ａのフローチャートにしたがって動作する。図１３Ａのフローチャートは、必要に応じて繰り返される。

【0114】

具体的には、負荷計測部８１５は、図３Ａで説明したデータ転送（ステップＳ３）の後に、送信側端末８１の負荷を計測する（ステップＳ７）。

【0115】

図１３Ｂは、第２の実施形態による異常診断装置８の送信側端末８１の動作例において、負荷計測を示すフローチャートである。負荷計測は、図１３Ｂのフローチャートにしたがって実行される。

【0116】

具体的には、負荷計測部８１５は、負荷計測を開始した後（ステップＳ７１）、送信側端末８１のＣＰＵの使用率（％）が許容値ＣＰＵ＿ｔｈを超えたか否かを判定する（ステップＳ７２）。

【0117】

ＣＰＵの使用率が許容値ＣＰＵ＿ｔｈを超えた場合（ステップＳ７２：Ｙｅｓ）、診断切替部３５は、転送・診断部８１２から送信された診断モード切替信号に応じて、診断モードを切り替える（ステップＳ７３）。これにより、診断部３２は、通常の二次異常診断に加えて、送信側端末８１の転送・診断部８１２が省略した一次異常診断の診断項目の診断を実施する。

【0118】

一方、ＣＰＵの使用率が許容値ＣＰＵ＿ｔｈを超えていない場合（ステップＳ７２：Ｎｏ）、負荷計測部８１５は、診断データの伝送負荷率（ｐｐｓ）が許容値Ｔｒａｎｓ＿ｔｈを超えたか否かを判定する（ステップＳ７４）。

【0119】

診断データの伝送負荷率（ｐｐｓ）が許容値Ｔｒａｎｓ＿ｔｈを超えた場合（ステップＳ７４：Ｙｅｓ）、診断切替部３５は、転送・診断部８１２から送信された診断モード切替信号に応じて、診断モードを切り替える（ステップＳ７３）。

【0120】

一方、診断データの伝送負荷率（ｐｐｓ）が許容値Ｔｒａｎｓ＿ｔｈを超えていない場合（ステップＳ７４：Ｎｏ）、負荷計測部８１５は、負荷計測を終了する（ステップＳ７５）。

【0121】

図１３Ｃは、第２の実施形態による異常診断装置８の送信側端末８１の動作の変形例を示すフローチャートである。図１３Ｃのフローチャートは、必要に応じて繰り返される。ＣＰＵの使用率または伝送負荷率が許容値を超える場合、図１３Ｃに示すように、転送・診断部８１２は、一次異常診断のうちのヘッダ情報判定処理を省略してもよい。

【0122】

図１３Ｄは、第２の実施形態による異常診断システム１のクラウド診断装置３の動作例を示すフローチャートである。第２の実施形態において、クラウド診断装置３による異常診断は、図１３Ｄのフローチャートにしたがって実施される。図１３Ｄのフローチャートは、必要に応じて繰り返される。

【0123】

具体的には、図９Ａで説明した新規の診断データの受信の有無の判定において、新規の診断データが受信された場合（ステップＳ６２：Ｙｅｓ）、診断切替部３５は、診断モード切替信号が受信されたか否かを判定する（ステップＳ６４）。

【0124】

診断モード切替信号が受信された場合（ステップＳ６４：Ｙｅｓ）、診断切替部３５は、二次異常診断に加えて制御システム２側で省略されたヘッダ情報判定処理を実施するように診断部３２の診断モードを切り替える。これにより、診断部３２は、ＤＰＩ判定処理（ステップＳ６３）に加えてヘッダ情報判定処理（ステップＳ４）を実施する。

【0125】

一方、診断モード切替信号が受信されていない場合（ステップＳ６４：Ｎｏ）、診断切替部３５は、診断モードを切り替えず、診断部３２は、ＤＰＩ判定処理（ステップＳ６３）のみを実施する。

【0126】

第２の実施形態によれば、運用環境の変化等によって異常診断装置８にかかる負荷が増大した場合でも、動的に一次異常診断をクラウド側で分担できるため、診断機能を維持して可用性を向上させることができる。

【0127】

（第３の実施形態）
次に、学習モードと診断モードとを選択可能な第３の実施形態について説明する。

【0128】

図１４Ａは、第３の実施形態による異常診断装置８を示すブロック図である。

【0129】

第３の実施形態において、送信側端末８１は、第１の実施形態の構成に加えて、更に、第１モード切替部８１６を有する。

【0130】

第１モード切替部８１６は、転送・診断部８１２の動作モードを、診断モードと学習モードとの間で切り替える。

【0131】

転送・診断部８１２は、診断モードでは、第１判定テーブルに基づいて一次異常診断を実施する。一方、転送・診断部８１２は、学習モードでは、送信側端末８１に入力された第１判定テーブルを第１判定テーブル保存部８１３に登録する。

【0132】

図１４Ｂは、第３の実施形態によるクラウド診断装置３を示すブロック図である。

【0133】

第３の実施形態において、クラウド診断装置３は、第１の実施形態の構成に加えて、更に、第２モード切替部３７と、表示部３６とを有する。

【0134】

第２モード切替部３７は、診断部３２の動作モードを、診断モードと学習モードとの間で切り替える。

【0135】

診断部３２は、診断モードでは、第２判定テーブルに基づいて二次異常診断を実施する。一方、診断部３２は、学習モードでは、受信された診断データに基づいて第２判定テーブルを第２判定テーブル保存部３３に登録する。

【0136】

図１５Ａは、第３の実施形態による異常診断装置８の送信側端末８１の動作例を示すフローチャートである。第３の実施形態による異常診断システム１のうち、異常診断装置８の送信側端末８１は、図１５Ａのフローチャートにしたがって動作する。図１５Ａのフローチャートは、必要に応じて繰り返される。

【0137】

図１５Ａのフローチャートは、図３Ａのフローチャートに対しして、学習モードを実行するための工程（ステップＳ８１～ステップＳ８５）が追加されている点で異なり、他の点で同様である。以下の説明では、図３Ａと異なる工程についてのみ詳細に説明する。

【0138】

先ず、転送・診断部８１２は、転送・診断部８１２の動作モードが学習モードであるか否かを判定する（ステップＳ８１）。

【0139】

学習モードでない場合（ステップＳ８１：Ｎｏ）、転送・診断部８１２は、図３Ａで説明した診断工程を実行する（ステップＳ１～ステップＳ５）。

【0140】

一方、学習モードである場合（ステップＳ８１：Ｙｅｓ）、転送・診断部８１２は、学習処理を開始する（ステップＳ８２）。

【0141】

学習処理を開始した後、転送・診断部８１２は、新規の診断データが受信されたか否かを判定する（ステップＳ８３）。ただし、このとき受信される診断データは、診断には用いられずに第１判定テーブルの作成に用いられる。

【0142】

新規の診断データが受信された場合（ステップＳ８３：Ｙｅｓ）、転送・診断部８１２は、受信された診断データに含まれる送信元ＩＰアドレスおよび送信先ＩＰアドレスが、第１判定テーブル保存部８１３に登録済みであるか否かを判定する（ステップＳ８４）。

【0143】

送信元ＩＰアドレスおよび送信先ＩＰアドレスが登録済みでない場合（ステップＳ８４：Ｎｏ）、転送・診断部８１２は、受信された診断データに含まれる送信元ＩＰアドレスおよび送信先ＩＰアドレスを、第１判定テーブルとして第１判定テーブル保存部８１３に登録する（ステップＳ８５）。

【0144】

一方、送信元ＩＰアドレスおよび送信先ＩＰアドレスが登録済みの場合（ステップＳ８４：Ｙｅｓ）、転送・診断部８１２は、学習モードであるか否かの判定を繰り返す（ステップＳ８１）。

【0145】

このようにして、新たな診断データの受信に応じて未登録の送信元ＩＰアドレスおよび送信先ＩＰアドレスを第１判定テーブル保存部８１３に逐次登録することで、第１判定テーブルを作成する。

【0146】

学習モードによって第１判定テーブルを作成した後は、第１モード切替部８１６によって転送・診断部８１２の動作モードを診断モードに切り替え、転送・診断部８１２によって第１判定テーブルを用いた第１の異常診断を実施する。学習モードから診断モードへの切り替えは、例えば電源投入後一定時間後に自動で実行してもよく、または、ユーザ操作に応じた任意のタイミングで実行してもよい。

【0147】

図１５Ｂは、第３の実施形態による異常診断システム１のクラウド診断装置３の動作例を示すフローチャートである。第３の実施形態による異常診断システム１のうち、クラウド診断装置３は、図１５Ｂのフローチャートにしたがって動作する。図１５Ｂのフローチャートは、必要に応じて繰り返される。

【0148】

図１５Ｂのフローチャートは、図９Ａのフローチャートに対しして、学習モードを実行するための工程（ステップＳ９１～ステップＳ９５）が追加されている点で異なり、他の点で同様である。以下の説明では、図９Ａと異なる工程についてのみ詳細に説明する。

【0149】

先ず、診断部３２は、診断部３２の動作モードが学習モードであるか否かを判定する（ステップＳ９１）。

【0150】

学習モードでない場合（ステップＳ９１：Ｎｏ）、診断部３２は、図９Ａで説明した診断工程を実行する（ステップＳ６１～ステップＳ６３）。

【0151】

一方、学習モードである場合（ステップＳ９１：Ｙｅｓ）、診断部３２は、学習処理を開始する（ステップＳ９２）。

【0152】

学習処理を開始した後、診断部３２は、新規の診断データが受信されたか否かを判定する（ステップＳ９３）。ただし、このとき受信される診断データは、診断には用いられずに第２判定テーブルの作成に用いられる。

【0153】

新規の診断データが受信された場合（ステップＳ９３：Ｙｅｓ）、診断部３２は、受信された診断データのフィールド毎に、制御値の最小値および最大値の更新の要否を判定する（ステップＳ９４）。要否の判定は、制御値が既登録か否かの判定であってもよい。

【0154】

制御値の最小値および最大値の更新が必要である場合、（ステップＳ９４：Ｙｅｓ）、診断部３２は、制御値の最小値および最大値を、第２判定テーブルとして第２判定テーブル保存部３３に登録する（ステップＳ９５）。

【0155】

一方、制御値の最小値および最大値の更新が不要である場合（ステップＳ９４：Ｙｅｓ）、診断部３２は、学習モードであるか否かの判定を繰り返す（ステップＳ９１）。

【0156】

第３の実施形態によれば、ユーザが手動で判定テーブルを作成する必要がなくなるため、利便性を向上させることができる。

【0157】

本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれると同様に、特許請求の範囲に記載された発明とその均等の範囲に含まれるものである。

【符号の説明】

【0158】

１ 異常診断システム、２ 制御システム、８ 異常診断装置、８１ 送信側端末、８２ 受信側端末

【図1】

【図2A】

【図2B】

【図3A】

【図3B】

【図4】

【図5】

【図6A】

【図6B】

【図7】

【図8】

【図9A】

【図9B】

【図10】

【図11】

【図12A】

【図12B】

【図13A】

【図13B】

【図13C】

【図13D】

【図14A】

【図14B】

【図15A】

【図15B】