WO2018173292A1 - ゲートウェイ装置、優先度変更方法及び優先度変更プログラム - Google Patents

Abstract

ゲートウェイ装置（１－１）は、フレームのプロトコルタイプとフレームの特徴を示すフレームパターンとが対応付けられたリソース管理テーブル（２１－１）を格納するメモリ（２０）を持つ。ゲートウェイ装置（１－１）は、受信ＮＩＣ（６０）でフレームを受信し、フレームのプロトコルタイプがリソース管理テーブル（２１－１）に存在するか判定し、プロトコルタイプがリソース管理テーブル（２１－１）に存在する場合、そのプロトコルタイプに対応するフレームパターンに、受信されたフレームの内容が合致するか判定し、判定結果に応じて、リソース管理テーブル（２１－１）に存在すると判定されたプロトコルタイプの処理の優先度を上げる。

Description

ゲートウェイ装置、優先度変更方法及び優先度変更プログラム

　この発明は、フレームを受信して処理する、ゲートウェイ装置、優先度変更方法及び優先度変更プログラムに関する。

　従来のＥｔｈｅｒｎｅｔ（登録商標）上の通信ゲートウェイ装置では、ネットワーク全体のＱｏＳ（Ｑｕａｌｉｔｙ　ｏｆ　Ｓｅｒｖｉｃｅ）を保つために、ネットワーク機器間でＱｏＳ向けのプロトコルを利用することにより、ネットワーク全体として、ネットワーク品質を担保している。例えば特許文献１では、フレームにＱｏＳの種別を付与し、親局と子局との間で、ＱｏＳ伝送の可否を確認しつつ、ＱｏＳを担保する手法について記載がある。

国際公開第２００８／００４５９２号パンフレット

　しかしながら、近年、ＢＡＣ－ｎｅｔなどの制御用プロトコルとＴＣＰ／ＩＰなどの汎用プロトコルを統合的に管理・制御可能なゲートウェイ装置が増えている。こうした機器では、制御用プロトコルを優先的に処理する必要があるが、ＴＣＰ／ＩＰプロトコルの処理の複雑さから、ＣＰＵリソース及びメモリが多く消費されてしまい、制御用プロトコルの処理が遅れるという課題があった。
　例えば、制御用プロトコルを介して、ゲートウェイ装置の上位局から下位局に対して緊急停止を指示された際、すでにゲートウェイ装置で処理の複雑な汎用プロトコルを処理している場合、ゲートウェイ装置では制御用プロトコルの通信転送処理が実施できず、緊急停止の処理が遅れるという課題があった。

　この発明は、制御用プロトコルで受信したフレームの内容に応じて、ゲートウェイ装置におけるアプリケーション処理に対するリソースを動的に変更することで、特定のプロトコル処理を優先的に実施可能とすることを目的とする。

　この発明のゲートウェイ装置は、
　フレームの通信に使用するプロトコルの種類を示すプロトコルタイプと、前記フレームの特徴を示すフレームパターンとが対応付けられたフレーム情報を記憶する記憶部と、
　受信装置を介してフレームを受信し、受信したフレームのプロトコルタイプを検出し、
検出した前記プロトコルタイプが前記フレーム情報に登録されているか判定する受信制御部と、
　前記受信制御部によって前記プロトコルタイプが前記フレーム情報に登録されていると判定された場合に、登録されている前記プロトコルタイプに対応する前記フレームパターンに、前記プロトコルタイプが検出された前記フレームの内容が合致するかどうかを判定し、判定結果に応じて、前記フレーム情報に登録されていると判定された前記プロトコルタイプの処理の優先度を上げる優先度変更部と
を備える。

　本発明によれば、制御用プロトコルで受信したフレームの内容に応じて、特定のプロトコル処理を優先的に実施できるゲートウェイ装置を提供することができる。

実施の形態１の図で、ゲートウェイ装置１－１のハードウェア構成図。 実施の形態１の図で、プロセッサ１０によって実現される機能要素を示す図。 実施の形態１の図で、リソース管理テーブル２１－１を示す図。 実施の形態１の図で、ゲートウェイ装置１－１の起動時のフローチャート。 実施の形態１の図で、ゲートウェイ装置１－１がフレームを受信する場合の処理を示すフローチャート。 実施の形態１の図で、ゲートウェイ装置１－１の変形例を示す図。 実施の形態２の図で、ゲートウェイ装置１－２の機能要素を示す図。 実施の形態２の図で、ゲートウェイ装置１－２のメモリ２０を示す図。 実施の形態２の図で、定常状態の複数のフレームを、ログとして蓄積する方法を示すフローチャート。 実施の形態２の図で、定常状態のフレームをログとして蓄積した後の処理を示すフローチャート。 実施の形態２の図で、リソース管理テーブル２１－２を示す図。 実施の形態２の図で、リソース管理テーブル２１－２の設定以降の処理を示すフローチャート。 実施の形態３の図で、異常状態ログの取得後の処理を示すフローチャート。 実施の形態３の図で、リソース管理テーブル２１－３を示す図。 実施の形態３の図で、リソース管理テーブル２１－３への設定後の処理を示すフローチャート。

実施の形態１．
＊＊＊構成の説明＊＊＊
　図１は、組込み機器である実施の形態１のゲートウェイ装置１－１のハードウェア構成図である。図１において、ゲートウェイ装置１－１はソフトウェアによってフレームの送受信を行う。

　ゲートウェイ装置１－１は、コンピュータである。ゲートウェイ装置１－１は、プロセッサ１０、メモリ２０、二次記憶装置３０、入力デバイス４０、出力デバイス５０、受信ＮＩＣ（Ｎｅｔｗｏｒｋ　Ｉｎｔｅｒｆａｃｅ　Ｃｏｎｔｒｏｌｌｅｒ）６０、送信ＮＩＣ７０を備えている。プロセッサ１０は、信号線９０を介して他のハードウェアと接続され、これら他のハードウェアを制御する。

　プロセッサ１０は、演算処理を行うＩＣ（Ｉｎｔｅｇｒａｔｅｄ　Ｃｉｒｃｕｉｔ）である。プロセッサ１０は、具体例としては、ＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）、ＤＳＰ（Ｄｉｇｉｔａｌ　Ｓｉｇｎａｌ　Ｐｒｏｃｅｓｓｏｒ）、ＧＰＵ（Ｇｒａｐｈｉｃｓ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）である。

　メモリ２０にはプログラムの実行コード及び実行データが保持される。また、記憶部９２０であるメモリ２０には、フレーム情報９２１－１であるリソース管理テーブル２１－１が記憶される。メモリ２０は、読み書きが可能な記憶装置である。メモリ２０の具体例としては、ＳＲＡＭ（Ｓｔａｔｉｃ　Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）、ＤＲＡＭ（Ｄｙｎａｍｉｃ　Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）がある。

　二次記憶装置３０は、読み書きが可能な不揮発性の記憶装置である。二次記憶装置３０にはプログラムが格納される。二次記憶装置３０に格納されているプログラムは、ハードウェアの起動時など、必要に応じてメモリ２０に展開される。二次記憶装置３０には、ゲートウェイ装置１－１の機能を実現するためのプログラム及び他のデータが記憶される。二次記憶装置３０は、具体例としては、磁気ディスク装置である。また、二次記憶装置３０は、光ディスク、コンパクトディスク、ブルーレイ（登録商標）ディスク、ＤＶＤ（Ｄｉｇｉｔａｌ　Ｖｅｒｓａｔｉｌｅ　Ｄｉｓｋ）といった可搬記憶媒体を使用する記憶装置であってもよい。

　入力デバイス４０は、ユーザからの入力操作に応じて、プロセッサ１０に対し入力状態を通知する。出力デバイス５０はプロセッサ１０の指示により、ＬＥＤの表示のようなユーザに対する通知を出力する。

　受信ＮＩＣ６０は、上位の局からフレームを受信し、プロセッサ１０に通知する。送信ＮＩＣ７０はプロセッサ１０の指示により下位の局にフレームを送信する。受信ＮＩＣ６０は受信装置９６０である。

　図２は、プロセッサ１０によって実現される機能要素を示す。ゲートウェイ装置１－１は、機能要素として、第１プロトコル処理部１１、第２プロトコル処理部１２、第２プロトコルフレームパターン解釈部１３、第２プロトコルリソース変更部１４、フレーム受信部１５、ユーザ指示管理部１６を備えている。
（１）第１プロトコル処理部１１は、プロトコル１を処理する。プロトコル１は、以下、第１プロトコルと記す。第１プロトコルはＴＣＰ／ＩＰプロトコルを想定する。第１プロトコル処理部１１は、第１プロトコルのフレームの内容に応じて、アプリケーション処理を行う。例えば、第１プロトコル処理部１１は、ＴＣＰ／ＩＰプロトコル上で構築されたアプリケーションに対する処理を行う。処理の内容は、送信ＮＩＣ７０を介したフレームの送信、あるいは、入力デバイス４０、出力デバイス５０の操作である。
（２）第２プロトコル処理部１２は、プロトコル２を処理する。プロトコル２は、以下、第２プロトコルと記す。第２プロトコルは制御用プロトコルを想定する。第２プロトコル処理部１２は、第２プロトコルのフレームの内容に応じて、アプリケーション処理を行う。例えば、第２プロトコル処理部１２は、ＢＡＣ－ｎｅｔプロトコルなどの制御用プロトコル上に構築されたアプリケーションに対する処理を行う。
（３）第２プロトコルフレームパターン解釈部１３は、第２プロトコルのフレームパターンを解釈する。第２プロトコルフレームパターン解釈部１３は、以下、解釈部１３と記す。
（４）第２プロトコルリソース変更部１４は、第２プロトコルに割り当てられるリソースを変更する。第２プロトコルリソース変更部１４は、以下、変更部１４と記す。
（５）フレーム受信部１５は、受信ＮＩＣ６０を介してフレームを受信する。
（６）ユーザ指示管理部１６は、入力デバイス４０によってユーザから入力された情報を処理する。ユーザ指示管理部１６は、以下、管理部１６と記す。
（７）解釈部１３と変更部１４とは、優先度変更部９１３を構成する。また、フレーム受信部１５は、受信制御部９１５である。

　第１プロトコル処理部１１、第２プロトコル処理部１２、解釈部１３、変更部１４、フレーム受信部１５及び管理部１６の機能は、ソフトウェアにより実現される。二次記憶装置３０には、第１プロトコル処理部１１、第２プロトコル処理部１２、解釈部１３、変更部１４、フレーム受信部１５及び管理部１６の機能を実現するプログラムが記憶されている。このプログラムは、プロセッサ１０により読み込まれ実行される。これにより、第１プロトコル処理部１１、第２プロトコル処理部１２、解釈部１３、変更部１４、フレーム受信部１５及び管理部１６の機能が実現される。具体的には、図２に示す第１プロトコル処理部１１、第２プロトコル処理部１２、解釈部１３、変更部１４、フレーム受信部１５及び管理部１６は、実行コード及び実行データとしてメモリ２０上に展開される。

　図１では、プロセッサ１０は、１つだけ示されている。しかし、ゲートウェイ装置１－１は、プロセッサ１０を代替する複数のプロセッサを備えていてもよい。これら複数のプロセッサは、第１プロトコル処理部１１、第２プロトコル処理部１２、解釈部１３、変更部１４、フレーム受信部１５及び管理部１６のプログラムの実行を分担する。それぞれのプロセッサは、プロセッサ１０と同じように、演算処理を行うＩＣである。

　図３は、リソース管理テーブル２１－１を示す図である。リソース管理テーブル２１－１には、ユーザから入力された、プロトコルタイプ２１ａ、フレームパターン２１ｂ、リソース状態２１ｃが登録されている。リソース管理テーブル２１－１では、フレームの通信に使用するプロトコルの種類を示すプロトコルタイプ２１ａと、フレームの特徴を示すフレームパターン２１ｂと、リソース状態２１ｃとが対応付けられている。図３は、レコード２１ｄが登録された状態である。

＊＊＊動作の説明＊＊＊
　図４は、ゲートウェイ装置１－１の起動時のフローチャートである。図４は、レコード２１ｄが登録される処理を示す。図４を参照してゲートウェイ装置１－１の起動時の動作を説明する。
　ステップＳ１１において、管理部１６は、ユーザが入力デバイス４０を介して入力する情報を、リソース管理テーブル２１－１に登録する。ユーザが入力デバイス４０を介して入力する情報は、プロトコルタイプ２１ａ、フレームパターン２１ｂ、リソース変更値としてのリソース状態２１ｃである。
　ステップＳ１２において、管理部１６は、ユーザから入力された内容を、レコード２１ｄとしてリソース管理テーブル２１－１に登録し保存する。

　図５は、ゲートウェイ装置１－１がリソース管理テーブル２１－１に登録されている内容のフレームを受信した場合の処理を示すフローチャートである。図５を参照して、第１プロトコル処理部１１が第１プロトコルのフレーム処理を実行中に、リソース管理テーブル２１－１に登録されているフレームが受信された場合の処理を説明する。
　ステップＳ２１において、受信制御部９１５は、受信装置９６０を介してフレームを受信し、受信したフレームのプロトコルタイプを検出する。具体的には、第１プロトコル処理部１１による第１プロトコルのフレーム処理の実行中に、フレーム受信部１５がフレームを受信する。この例では、フレーム受信部１５は、第２プロトコルのフレームを受信する。
　ステップＳ２２において、フレーム受信部１５は、フレームのプロトコルタイプを検出する。この場合は第２プロトコルが検出される。

　ステップＳ２３において、受信制御部９１５であるフレーム受信部１５は、検出したプロトコルタイプが、フレーム情報９２１－１であるリソース管理テーブル２１－１に登録されているか判定する。リソース管理テーブル２１－１は図３の状態であるので、フレーム受信部１５は、第２プロトコルがリソース管理テーブル２１－１に登録されていると判定する。
　ステップＳ２４において、フレーム受信部１５は、解釈部１３に、受信したフレームを送る。

　ステップＳ２５において、優先度変更部９１３は、受信制御部９１５によってプロトコルタイプがフレーム情報９２１－１に登録されていると判定された場合に、登録されているプロトコルタイプ２１ａに対応するフレームパターン２１ｂに、プロトコルタイプが検出されたフレームの内容が合致するかどうかを判定する。解釈部１３は、フレーム受信部１５から受け取ったフレームの内容が、リソース管理テーブル２１－１に登録されているフレームパターン２１ｂと一致するか判定する。今回の場合、解釈部１３は、受信されたフレームが緊急停止フラグを含むか判定する。この例では、解釈部１３は、リソース管理テーブル２１－１に登録されているレコード２１ｄのフレームパターン２１ｂとフレーム内容とが一致すると判定する。つまりこの例では、受信されたフレームは緊急停止フラグを含むとする。
　ステップＳ２６において、解釈部１３は、変更部１４を呼び出す。解釈部１３は、変更部１４に対して、リソース管理テーブル２１－１のレコード２１ｄのリソース状態２１ｃの内容に第２プロトコル処理部１２をリソース状態を変更するように、指令する。

　ステップＳ２７において、変更部１４は、第２プロトコル処理部１２を、リソース管理テーブル２１－１のレコード２１ｄのリソース状態２１ｃに変更する。即ち、優先度変更部９１３である変更部１４は、フレーム情報９２１－１に登録されていると判定されたプロトコルタイプ２１ａの処理の優先度を上げる。
　ステップＳ２８において、ＯＳ（Ｏｐｅｒａｔｉｎｇ　Ｓｙｓｔｅｍ）のスケジュラーが動作する場合、ステップＳ２７で実施された変更に従って、スケジュラーは第２プロトコル処理部１２を、他のプロトコル処理部よりも優先して動作させる。なお、ステップＳ２５でＹＥＳ、ステップＳ２６、ステップＳ２７と流れる処理の場合、優先度変更部９１３は、フレームパターン２１ｂに、プロトコルタイプが検出されたフレームの内容が合致すると判定した場合に、フレーム情報９２１－１に登録されていると判定されたプロトコルタイプ２１ａの処理の優先度を上げる。

　検出されたプロトコルタイプが第２プロトコルでない場合（ステップＳ２３でＮＯ）、あるいは、ステップＳ２５でＮＯの場合は、ステップＳ２９において第１プロトコル処理部１１が動作を続ける。

＊＊＊実施の形態１の効果＊＊＊
　ゲートウェイ装置１－１は、受信されたフレームの内容に応じて、処理するプロトコルの優先度を変更するので、特定のプロトコルの処理を優先的に実施することが可能となる。以上の説明では、第２プロトコルの処理の優先度を上げたが、これに限ることなく、第１プロトコル処理部１１を停止するなど、他の高優先度の処理を止めることにより、第２プロトコルの処理の優先度を相対的に向上させてもよい。

　また、今回の例では、単一のフレームを受信した場合にリソースの変更を行ったが、複数のフレームが決められた順で到着した場合に、優先度の変更を行ってもよい。この場合、解釈部１３は、複数のフレームの受信履歴を保存可能とする。複数のフレームを受信した場合は、実施の形態２及び実施の形態３で述べる。

＊＊＊他の構成＊＊＊
＜変形例１＞
　実施の形態１では、第１プロトコル処理部１１、第２プロトコル処理部１２、解釈部１３、変更部１４、フレーム受信部１５及び管理部１６の機能がソフトウェアで実現された。しかし、変形例１として、第１プロトコル処理部１１、第２プロトコル処理部１２、解釈部１３、変更部１４、フレーム受信部１５及び管理部１６の機能はハードウェアで実現されてもよい。この変形例１について、実施の形態１と異なる点を説明する。

　図６は、ゲートウェイ装置１－１の変形例１を示す。図６を参照して、変形例１に係るゲートウェイ装置１－１の構成を説明する。第１プロトコル処理部１１、第２プロトコル処理部１２、解釈部１３、変更部１４、フレーム受信部１５及び管理部１６の機能がハードウェアで実現される場合、ゲートウェイ装置１－１は、プロセッサ１０に代えて、処理回路８０を備える。処理回路８０は、第１プロトコル処理部１１、第２プロトコル処理部１２、解釈部１３、変更部１４、フレーム受信部１５及び管理部１６の機能を実現する専用の電子回路である。

　処理回路８０は、単一回路、複合回路、プログラム化したプロセッサ、並列プログラム化したプロセッサ、ロジックＩＣ、ＧＡ（Ｇａｔｅ　Ａｒｒａｙ）、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ　Ｓｐｅｃｉｆｉｃ　Ｉｎｔｅｇｒａｔｅｄ　Ｃｉｒｃｕｉｔ）、ＦＰＧＡ（Ｆｉｅｌｄ－Ｐｒｏｇｒａｍｍａｂｌｅ　Ｇａｔｅ　Ａｒｒａｙ）が想定される。第１プロトコル処理部１１、第２プロトコル処理部１２、解釈部１３、変更部１４、フレーム受信部１５及び管理部１６の機能を１つの処理回路８０で実現してもよいし、第１プロトコル処理部１１、第２プロトコル処理部１２、解釈部１３、変更部１４、フレーム受信部１５及び管理部１６の機能を複数の処理回路に分散させて実現してもよい。

　＜変形例２＞
　変形例２として、一部の機能がハードウェアで実現され、他の機能がソフトウェアで実現されてもよい。つまり、第１プロトコル処理部１１、第２プロトコル処理部１２、解釈部１３、変更部１４、フレーム受信部１５及び管理部１６のうち、一部の機能がハードウェアで実現され、他の機能がソフトウェアで実現されてもよい。

　プロセッサ１０と処理回路８０とを、総称して「プロセッシングサーキットリー」という。つまり、各機能構成要素の機能は、プロセッシングサーキットリーにより実現される。

実施の形態２．
　図７～図１２を参照して実施の形態２のゲートウェイ装置１－２を説明する。
　図７は、ゲートウェイ装置１－２の機能要素を示す。図２に対して、図７はフレーム保存部１７及びフレームログ解釈部１８が追加されている。ゲートウェイ装置１－２のハードウェア構成は図１と同じである。ゲートウェイ装置１－２は、定常状態の一連のフレームのフレームパターンに基づき、定常状態と異なる一つあるいは複数のフレームを受信したと判定した場合に、特定のプロトコルの処理の優先度を上げる。

　実施の形態２で想定する定常状態とは、以下のようである。例えば、フレームのオフセット位置がペイロードの３バイト目であるとする。連続するフレームにおいて、３バイト目が、０ｘｆ０，０ｘｆ１，０ｘｆ２，，，０ｘｆｆとなり、再度０ｘｆ０となることを想定している。これらの一連のフレームで制御通信することを想定している。定常状態とは、この例のように、あるフレームの後に必ず決まったフレームが到着する状態である。上記の例では、定常状態では、０ｘｆ１，０ｘｆ２，，，，，０ｘｆｆのフレーム群で一周期である。

　フレーム保存部１７は、図９で後述する複数フレームの取得時に、フレーム受信部１５から送付されたフレームを、フレームログ記憶領域２２に保存する。フレームログ記憶領域２２は例えば、メモリ２０に存在する。
　図８は、ゲートウェイ装置１－２のメモリ２０を示す。メモリ２０はリソース管理テーブル２１－２及びフレームログ記憶領域２２を有する。フレームログ記憶領域２２はメモリ２０に確保しているが、二次記憶装置３０あるいは外部記憶装置としてのＨＤＤ、ＳＤＤなどの外部記憶装置に設けてもよい。フレームログ記憶領域２２には、フレーム保存部１７から送付されたフレームが保存される。

　フレームログ解釈部１８は、フレームログ記憶領域２２の保存データから定常状態のフレームログを解釈し、通常状態のフレームパターンとしてリソース管理テーブル２１－２のフレームパターン２１ｂに登録する。

　図９は、定常状態の複数のフレームを、ログとして蓄積する方法を示すフローチャートである。

　ステップＳ３１において、ゲートウェイ装置１－２の起動時に、フレーム受信部１５は、ユーザによって、第２プロトコルのフレームを取得するように設定される。具体的には、ユーザは、入力デバイス４０を使用し、管理部１６を介して第２プロトコルのフレームを取得することをフレーム受信部１５に設定する。
　ステップＳ３２において、フレームを受信した場合、フレーム受信部１５は、フレームのプロトコルタイプを判定する。フレーム受信部１５の検出したプロトコルタイプが第２プロトコルに一致した場合、処理はステップＳ３３へ進み、第２プロトコルに一致しない場合、処理はステップＳ３５へ進む。
　ステップＳ３３において、フレーム受信部１５は、第２プロトコルの場合、フレームをフレーム保存部１７に渡す。

　ステップＳ３４において、フレーム保存部１７は、フレーム受信部１５から渡されたフレームを、フレームログ記憶領域２２に格納する。
　ステップＳ３５において、フレーム受信部１５は、プロトコルタイプに応じて、フレームを該当するプロトコル処理部に渡す。この例では、受信したフレームのプロトコルタイプは第２プロトコルなので、フレーム受信部１５は第２プロトコル処理部１２にフレームを渡す。

　図１０は、定常状態のフレームをログとして蓄積した後の処理を示す。
　ステップＳ４１において、フレームログ解釈部１８は、フレームログ記憶領域２２に保存されているプロトコルタイプが同じ定常状態の複数のフレームから、定常状態のフレームパターンを抽出する。フレームログ解釈部１８には定常状態のフレームパターンを抽出するための抽出条件が設定されているので、フレームログ解釈部１８は、定常状態のフレームパターンを抽出することができる。抽出の方法の一例としては、フレームログ解釈部１８は、ある特定のペイロードを検索キーとし、検索キーと一致する複数のフレームを抽出する。複数のフレームを抽出した場合、その間のフレームを、定常状態の受信フレーム群とする。その間とは、時間軸において、ペイロードが同一のフレーム群の先頭フレームと、最後フレームとの間の複数のフレームである。定常状態の定義で述べたように、ペイロードの３バイト目が０ｘｆ０、０ｘｆ１、０ｘｆ２，，，０ｘｆｆとなり、再度０ｘｆ０となる一連のフレームで制御通信することを想定する場合、３バイト目が、０ｘｆ０から０ｘｆｆまで変わる１６個のフレームである。つまり、フレームログ解釈部１８には、抽出条件として、ペイロードの３バイト目が０ｘｆ０、０ｘｆ１、０ｘｆ２，，，０ｘｆｆのフレームを抽出すべきことが規定されている。フレームログ解釈部１８により抽出されるフレームパターン抽出条件は、「ペイロードの３バイト目が０ｘｆ０、０ｘｆ１、０ｘｆ２，，，０ｘｆｆと周期的に連続する」ことである。

　ステップＳ４２において、フレームログ解釈部１８は、リソース管理ＴＢＬ２１－２に、抽出した定常状態のフレームパターン２１ｂを登録する。
　図１１は、リソース管理テーブル２１－２を示す。フレーム情報９２１－２であるリソース管理テーブル２１－２では、フレームパターン２１ｂとして、定常状態の複数のフレームの一群が、プロトコルタイプ２１ａに対応付けられている。図１１の例では、フレームパターン２１ｂとして「ペイロードの３バイト目が０ｘｆ０、０ｘｆ１、０ｘｆ２，，，０ｘｆｆと周期的に連続する」ことが登録される。また、リソース管理ＴＢＬ２１－２には、リソース状態２１ｃとして、第２プロトコルの処理を最優先にすることが設定される。リソース状態２１ｃの設定はユーザが入力デバイス４０を使用して管理部１６を介して設定しても良いし、フレームログ解釈部１８が設定する構成でもよい。以上の処理により、定常状態のフレーム群のフレームパターンが、リソース管理テーブル２１－２に登録される。

　図１２は、リソース管理テーブル２１－２の設定以降の処理を示すフローチャートである。図１２の処理は図５に記載の処理と同等であるので、異なる部分を説明する。図１２ではステップＳ２４－１が追加されている。ステップＳ２４－１において、解釈部１３は、フレーム受信部１５から送付されたフレームを蓄積する。

　ステップＳ２５ａにおいて、優先度変更部９１３は、受信制御部９１５による判定の結果、同一のプロトコルタイプの複数の受信されたフレームの同一のプロトコルタイプがフレーム情報９２１－２に登録されている場合に、同一のプロトコルタイプ２１ａに対応するフレームパターン２１ｂの示す複数のフレームの一群に、同一のプロトコルタイプの複数の受信されたフレームが合致するかどうかを判定する。優先度変更部９１３は、合致しないと判定した場合に（Ｓ２５ａでＮＯ）、同一のプロトコルタイプ２１ａの処理の優先度を上げる。
　解釈部１３は、ステップＳ２４－１で蓄積された一連のフレームが、リソース管理テーブル２１－２におけるレコード２１ｄのフレームパターン２１ｂに合致するか判定する。合致しないと判定した場合には処理はステップＳ２６に進む。つまり合致しない場合、受信フレームは正常状態のフレームではないので、処理はステップＳ２６に進む。合致すると判定した場合、処理はステップＳ２９に進む。合致する場合であれば受信フレームは正常状態のフレームだからである。その他のステップの処理は図５と同様である。

＊＊＊実施の形態２の効果＊＊＊
　実施の形態２のゲートウェイ装置１－２は、フレームログ解釈部１８がリソース管理テーブル２１－２にフレームパターンを登録するので、ユーザによる登録が不要である。
　また、ゲートウェイ装置１－２によれば、フレームパターン２１ｂとして一連のフレームのフレームパターンを登録するので、一連のフレームを受信した場合に対して、特定のプロトコルの処理を優先させるべきかどうかを判断できる。

　なお、実施の形態２では、フレームログ解釈部１８はゲートウェイ装置１－２上で動作させたが、他のホストマシンで動作させてもよい。また、フレームログの定常状態の抽出について、上記では、あるフレームをキーとした探索を行ったが、ディープラーニングなどを用いた他の方式で抽出を行ってもよい。

実施の形態３．
　図１３から図１５を参照して、実施の形態３のゲートウェイ装置１－３を説明する。ゲートウェイ装置１－３は、定常状態から異常状態となる直前の複数の定常状態のフレームから成るログ情報をもとに、特定のプロトコルの処理の優先度を上げる。

　異常状態のフレームとは、正常状態のフレームと異なる内容のフレームである。正常状態のフレームを、実施の形態２で説明した、ペイロードの３バイト目が０ｘｆ０から０ｘｆｆとなり、再度０ｘｆ０となる一連のフレームとする。この場合、異常状態のフレームとは、例えば、ペイロードの３バイト目が、０ｘｂ１，０ｘｂ２、０ｘｂ３で一周期となるような一連のフレームである。

　実施の形態３のゲートウェイ装置１－３は、フレームの受信傾向を元に、緊急停止などの高優先度のフレームを受信する前に、プロトコル処理の優先度を変更する。具体的には、ゲートウェイ装置１－３は、フレームの受信傾向が後述のリソース管理テーブル２１－３にフレームパターン２１ｂとして登録されている。フレームの受信傾向とは、正常状態から、異常状態へとフレームの内容が遷移する場合に、正常状態から異常状態に移る直前の、一連の正常状態の複数のフレームのフレームパターン２１ｂである。ゲートウェイ装置１－３は、ソース管理テーブル２１－３のフレームパターン２１ｂに合致する複数のフレームを受信した場合、異常状態のフレームが送られてくると予測する。この場合、ゲートウェイ装置１－３は、異常状態のフレームの受信を待つことなく、特定のプロトコルの処理の優先度を上げる。これにより、優先的に処理すべき異常状態を示すフレームが到着する前に、異常状態となると予想されるプロトコルの処理の優先度を事前に上げるができる。これにより、緊急性の高いフレームの処理を高速に実施できる。

　ゲートウェイ装置１－３の構成は、図７のゲートウェイ装置１－２と同じ構成である。またゲートウェイ装置１－３のハードウェア構成は図１と同一である。ゲートウェイ装置１－３は、上述のように、正常状態から異常状態へとフレームの内容が遷移する場合に、正常状態から異常状態に移る直前の、一連の正常状態の複数のフレームを取得するが、その取得方法は、実施の形態２の図９と同じである。

　図９のフローチャートに示す処理によってゲートウェイ装置１－３が、正常状態から異常状態に移る直前の、一連の正常状態の複数のフレームを取得するため、ゲートウェイ装置１－３の外部で異常状態を発生させ、異常状態の複数のフレームをログとしてゲートウェイ装置１－３に取得させる。

　図１３は、異常状態ログの取得後の処理を示す。図１３の前提として、図９の取得方法により、ゲートウェイ装置１－３は、正常状態のフレームと異常状態のフレームとの両方を取得している。これらのフレームは、フレームログ記憶領域２２に格納される。

　ステップＳ５１において、フレームログ解釈部１８は、定常状態のフレームパターンおよび異常状態の複数のフレームから、異常状態のフレームパターンを抽出する。フレームログ解釈部１８には異常状態のフレームパターンを抽出するための抽出条件が設定されているので、フレームログ解釈部１８は、異常状態のフレームパターンを抽出することができる。例えば前述の例によれば、抽出条件は、「ペイロードの３バイト目が０ｘｂ１、０ｘｂ２、０ｘｂ３と周期的に連続する」ことである。そしてフレームログ解釈部１８によって抽出される異常状態のフレームパターンは「ペイロードの３バイト目が０ｘｂ１、０ｘｂ２、０ｘｂ３と周期的に連続する」ことである。抽出の方法は例えば、ある特定のペイロードを検索のキーとし、このキーと一致するフレームを検索する。一致した場合は、その間のフレームを異常状態の受信フレーム群とする。

　ステップＳ５２において、フレームログ解釈部１８は、リソース管理テーブル２１－３に、フレームパターン２１ｂとして異常状態に至る直前までの正常状態の受信フレーム群と、その受信フレーム群のプロトコルタイプ２１ａを登録する。
　図１４は、この場合のフレーム情報９２１－３であるリソース管理テーブル２１－３を示す。フレーム情報９２１－３ではフレームパターン２１ｂとして、異常状態のフレームに切り替わる直前の、定常状態の複数のフレームの一群が、プロトコルタイプ２１ａに対応付けられている。図１４では、異常状態に至る直前までの正常状態の受信フレーム群のフレームパターンは、リソース管理テーブル２１－２のフレームパターン２１ｂと同じとする。なお、リソース管理テーブル２１－３のリソース状態２１ｃは、第２プロトコルの処理を最優先にするように設定される。リソース状態２１ｃの設定は、フレームログ解釈部１８が行ってもよいし、ユーザが入力デバイス４０及び管理部１６を介して行ってもよい。

　図１５は、リソース管理テーブル２１－３への設定後の処理を示すフローチャートである。図１５は実施の形態２の図１２と同様であるが、ステップＳ２５ａがステップＳ２５ｂとなっている。ステップＳ２５ｂではリソース管理テーブル２１－３を参照するためである。またステップＳ２５ｂでは、合致すると判定した場合には処理はステップＳ２６に進む。合致する場合、受信フレームは正常状態から異常状態に移ると予測されるため、処理はステップＳ２６に進む。合致しないと判定した場合、処理はステップＳ２９に進む。
　ステップＳ２５ｂにおいて優先度変更部９１３は、受信制御部９１５による判定の結果、同一のプロトコルタイプの複数の受信されたフレームの同一のプロトコルタイプがフレーム情報９２１－３に登録されている場合に、同一のプロトコルタイプ２１ａに対応するフレームパターン２１ｂの示す複数のフレームの一群に、同一のプロトコルタイプの複数の受信されたフレームが合致するかどうかを判定する。優先度変更部９１３は、合致すると判定した場合に（ステップＳ２５ｂでＹＥＳ）、同一のプロトコルタイプ２１ａの処理の優先度を上げる。

　以上の処理により、異常状態のフレームのように優先的なフレームが到着する前に、事前にプロトコル処理の優先度を変更することで、緊急性の高いフレームの処理を高速に実施可能となる。

　以上、本発明の実施の形態について説明したが、これらの実施の形態のうち、２つ以上を組み合わせて実施しても構わない。あるいは、これらの実施の形態のうち、１つを部分的に実施しても構わない。あるいは、これらの実施の形態のうち、２つ以上を部分的に組み合わせて実施しても構わない。なお、本発明は、これらの実施の形態に限定されるものではなく、必要に応じて種々の変更が可能である。

　１－１，１－２，１－３　ゲートウェイ装置、１０　プロセッサ、１１　第１プロトコル処理部、１２　第２プロトコル処理部、１３　解釈部、１４　変更部、１５　フレーム受信部、１６　管理部、１７　フレーム保存部、１８　フレームログ解釈部、２０　メモリ、２１－１，２１－２，２１－３　リソース管理テーブル、２２　フレームログ記憶領域、３０　二次記憶装置、４０　入力デバイス、５０　出力デバイス、６０　受信ＮＩＣ、７０　送信ＮＩＣ、９１５　受信制御部、９１３　優先度変更部、９２０　記憶部、９２１－１，９２１－２，９２１－３　フレーム情報、９６０　受信装置。

Claims (6)

1. 　フレームの通信に使用するプロトコルの種類を示すプロトコルタイプと、前記フレームの特徴を示すフレームパターンとが対応付けられたフレーム情報を記憶する記憶部と、
   　受信装置を介してフレームを受信し、受信したフレームのプロトコルタイプを検出し、
   検出した前記プロトコルタイプが前記フレーム情報に登録されているか判定する受信制御部と、
   　前記受信制御部によって前記プロトコルタイプが前記フレーム情報に登録されていると判定された場合に、登録されている前記プロトコルタイプに対応する前記フレームパターンに、前記プロトコルタイプが検出された前記フレームの内容が合致するかどうかを判定し、判定結果に応じて、前記フレーム情報に登録されていると判定された前記プロトコルタイプの処理の優先度を上げる優先度変更部と
   を備えるゲートウェイ装置。
2. 　前記優先度変更部は、
   　前記フレームパターンに、前記プロトコルタイプが検出された前記フレームの内容が合致すると判定した場合に、前記フレーム情報に登録されていると判定された前記プロトコルタイプの処理の優先度を上げる請求項１に記載のゲートウェイ装置。
3. 　前記記憶部は、
   　前記フレーム情報の前記フレームパターンとして、
   　定常状態の複数のフレームの一群が前記プロトコルタイプに対応付けられており、
   　前記優先度変更部は、
   　前記受信制御部による判定の結果、同一のプロトコルタイプの複数の受信されたフレームの前記同一のプロトコルタイプが前記フレーム情報に登録されている場合に、前記同一のプロトコルタイプに対応する前記フレームパターンの示す前記複数のフレームの前記一群に、前記同一のプロトコルタイプの前記複数の受信されたフレームが合致するかどうかを判定し、合致しないと判定した場合に、前記同一のプロトコルタイプの処理の優先度を上げる請求項１に記載のゲートウェイ装置。
4. 　前記記憶部は、
   　前記フレーム情報の前記フレームパターンとして、異常状態のフレームに切り替わる直前の、定常状態の複数のフレームの一群が前記プロトコルタイプに対応付けられており、
   　前記優先度変更部は、
   　前記受信制御部による判定の結果、同一のプロトコルタイプの複数の受信されたフレームの前記同一のプロトコルタイプが前記フレーム情報に登録されている場合に、前記同一のプロトコルタイプに対応する前記フレームパターンの示す前記複数のフレームの前記一群に、前記同一のプロトコルタイプの前記複数の受信されたフレームが合致するかどうかを判定し、合致すると判定した場合に、前記同一のプロトコルタイプの処理の優先度を上げる請求項１に記載のゲートウェイ装置。
5. 　コンピュータが、
   　フレームの通信に使用するプロトコルの種類を示すプロトコルタイプと、前記フレームの特徴を示すフレームパターンとが対応付けられたフレーム情報を記憶部に記憶し、
   　受信装置を介してフレームを受信し、受信したフレームのプロトコルタイプを検出し、検出した前記プロトコルタイプが前記フレーム情報に登録されているか判定し、
   　前記プロトコルタイプが前記フレーム情報に登録されていると判定された場合に、登録されている前記プロトコルタイプに対応する前記フレームパターンに、前記プロトコルタイプが検出された前記フレームの内容が合致するかどうかを判定し、判定結果に応じて、前記フレーム情報に登録されていると判定された前記プロトコルタイプの処理の優先度を上げる、
   優先度変更方法。
6. 　コンピュータに、
   　フレームの通信に使用するプロトコルの種類を示すプロトコルタイプと、前記フレームの特徴を示すフレームパターンとが対応付けられたフレーム情報を記憶部に記憶する記憶処理と、
   　受信装置を介してフレームを受信し、受信したフレームのプロトコルタイプを検出し、検出した前記プロトコルタイプが前記フレーム情報に登録されているか判定する受信制御処理と、
   　前記受信制御処理によって前記プロトコルタイプが前記フレーム情報に登録されていると判定された場合に、登録されている前記プロトコルタイプに対応する前記フレームパターンに、前記プロトコルタイプが検出された前記フレームの内容が合致するかどうかを判定し、判定結果に応じて、前記フレーム情報に登録されていると判定された前記プロトコルタイプの処理の優先度を上げる優先度変更処理と、
   を実行させる優先度変更プログラム。

Images