(57)【特許請求の範囲】
【請求項１】
ヘッダとデータフィールドを含むフレームが通信されるネットワークに接続され、所定のトリガ検知条件に基づいてネットワークを流れるフレームのうち必要なフレームを取り込むプロトコルアナライザにおいて、
Ｍａｓｋ＆Ｍａｔｃｈの使用とＩＤの指定とデータフィールドの使用との選択的組み合わせにより設定されたトリガ検知条件のそれぞれが論理表記に適した言語によって表記されたトリガ検知命令をコンパイルした結果が格納されるメモリと、
ネットワークを流れる上記フレームを受信する受信処理と、上記メモリから上記コンパイルされたトリガ検知命令を読み出して実行することにより、受信処理したフレームについてトリガ検知か否かを判別する判別処理と、判別処理の結果がトリガ検知である場合に処理するトリガ検知時処理と、を行うトリガ検知判別部と、
上記トリガ検知判別部のトリガ検知時処理に基づいて取り込んだフレームを記憶する記憶部と、
を有することを特徴とするプロトコルアナライザ。
【請求項２】
上記プロトコルアナライザは、更にトリガ検知条件を設定するためのアプリケーション実行部を有し、
このアプリケーション実行部は、ユーザによって、Ｍａｓｋ＆Ｍａｔｃｈの使用とＩＤの指定とデータフィールドの使用とを選択的に組み合わせてトリガ検知条件が複数設定され、
上記言語をラダー言語とし、上記設定されたトリガ検知条件のそれぞれをラダー言語で表記されて上記トリガ検知命令が設定される
ことを特徴とする請求項１に記載のプロトコルアナライザ。
【請求項３】
上記アプリケーション実行部は、
上記トリガ検知判別部へネットワーク監視開始とネットワーク監視終了とを管理し、
上記記憶部に記憶した取り込みフレームを読み出して表示するものである
ことを特徴とする請求項２に記載のプロトコルアナライザ。
【請求項４】
上記アプリケーション実行部は、
上記トリガ検知条件を設定する際に、ダイアログボックスを提供するもので、
そのダイアログボックス上にてＭａｓｋ＆Ｍａｔｃｈの使用とＩＤの指定とデータフィールドの使用との選択的な組み合わせを設定可能としている
ことを特徴とする請求項２に記載のプロトコルアナライザ。
【請求項５】
ネットワークを流れるヘッダとデータフィールドとを含むフレームが予め設定された所定のトリガ検知条件に合致するか否かを判別するトリガ検知装置において、
上記トリガ検知条件を、Ｍａｓｋ＆Ｍａｔｃｈの使用とＩＤの指定とデータフィールドの使用との選択的な組み合わせにより設定するとともに、設定したトリガ検知条件のそれぞれを論理表記に適した命令語によりトリガ検知命令を設定するトリガ検知命令設定手段と、
上記トリガ検知命令設定手段で設定されたトリガ検知命令をコンパイルするトリガ検知命令コンパイル手段と、
上記トリガ検知命令コンパイル手段によってコンパイルされたトリガ検知命令を格納されるメモリと、ネットワークを流れる上記フレームを受信する受信処理と、上記メモリのトリガ検知命令に基づいて上記受信処理したフレームが予め設定された所定のトリガ検知条件に合致するか否かを判別する判別処理と、判別処理の結果が条件合致である場合に処理するトリガ検知時処理と、を行うトリガ検知判別部と、
上記トリガ検知判別部のトリガ検知時処理に基づいて取り込んだフレームを記憶する記憶部と、
を有することを特徴とするトリガ検知装置。
【請求項６】
ネットワークを流れるヘッダとデータフィールドとを含むフレームが予め設定された所定のトリガ検知条件に合致するか否か判別するボードであって、
ホストに対して接続し、共有メモリを含むホストインタフェースと、
ネットワークを流れる上記フレームを取り込むネットインタフェースと、
Ｍａｓｋ＆Ｍａｔｃｈの使用とＩＤの指定とデータフィールドの使用との選択的な組み合わせにより設定された上記トリガ検知条件を論理表記に適した命令語により示したトリガ検知命令を上記共有メモリから読み出してコンパイルし、バイナリ命令に変換する変換手段と、
上記変換手段にて変換されたトリガ検知命令を格納するメモリと、
上記メモリに格納されたトリガ検知命令を実行し、上記ネットインタフェースから取り込んだフレームが予め設定された所定のトリガ検知条件に合致するか否かを判別する判別手段と、
上記判別手段の判別結果に基づいて所定のトリガ検知条件に合致するフレームを収集するフレーム収集部と、
を有することを特徴とするボード。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明はプロトコルアナライザ、トリガ検知装置、トリガ検知のためのプログラムが記録された記録媒体及びボードに関し、詳しくはプロトコルアナライザを利用してネットワークを流れるフレームが予め設定された所定のトリガ検知条件に合致するか否かを判別するプロトコルアナライザ、トリガ検知装置、トリガ検知のためのプログラムが記録された記録媒体及びボードに関する。
【０００２】
【従来の技術】
一般に、ネットワークには複数の端末をつないだり、制御装置や被制御装置をつなげて、データのやりとりやフレームやメッセージの通信を行なっている。
特にファクトリー・オートメーション（ＦＡ）の分野では、プログラマブル・コントローラを使う際に、リモートＩ／Ｏ通信することがある。この場合、プログラマブル・コントローラ側にマスタ局、Ｉ／Ｏ機器（デバイス）側にスレーブ局を設け、例えばデバイスネットと呼ばれるネットワーク上でデータやメッセージのやりとりを行なっている。
しかし、デバイス側で間違ったフレームを出したり、フレーム送信タイミングがおかしかったり、正常フレームが送出されても、途中でノイズによりデータがつぶれたりすると、プログラマブル・コントローラとデバイス間の通信エラーがおきる。
そこで、ネットワークに関する不具合の原因を追求したり、ネットワークの状態を正確に把握するために、ネットワーク上を流れるフレームを収集し解析を行なう装置として、プロトコルアナライザと呼ばれるものがある。
【０００３】
例えば、ネットワークはＣＡＮプロトコルと呼ばれるプロトコルを利用したデバイスネットと呼ばれるネットワークより構成される。
デバイスネットは、ファクトリー・オートメーション等に適用される分散型のネットワークで、ネットワークには各種通信装置や制御機器が接続され、伝送路には各種通信装置や制御機器に対する入力情報（メッセージ）及び各種通信装置や制御機器からの出力情報（メッセージ）等がフレームとして流れている。
ここで、プロトコルアナライザは、フレームを取りこぼさない、複雑なトリガ検知条件を設定したい等のユーザニーズを満たしつつ、ネットワークに流れるメッセージをネットワークに負荷をかけることなくモニタするものである。
プロトコルアナライザの基本的な機能は以下の２点である。
（１）フレーム収集機能
（２）フレーム表示機能
フレーム収集機能とは、ネットワーク上を流れるフレームを収集する機能で、予め設定したトリガ条件に基づいて、フレームを選択的にメモリに記憶する。フレームを選択するときには、後述するフィルタリング機能によって通過したフレームだけを収集するという方式が採用されている。
【０００４】
また、フレーム表示機能とは、収集したフレームをユーザに理解できる形式で表示する機能で、モニタ画面を介して各フレームの間隔を示す時間情報を時系列に表示する等の処理を行なう。また、収集したフレーム情報を加工して表示する場合もある。例えば、収集した全フレーム中におけるフレームの種類ごとの占有比率等である。
【０００５】
また、上記基本機能に加えて、以下の機能もある。
（３）フィルタリング機能
フィルタリング機能とは、事前に設定された分析対象のフレーム以外は収集せず、指定されたフレームのみを選択的に収集する機能である。この機能を使用することによって限られたリソース、つまりメモリ容量を有効に使用することができる。例えば、ノードやスレーブにアドレス番号を付し、特定のアドレス番号に着目して、そのアドレス番号を含むフレームだけを選択的に収集して、不必要なフレームのバッファリングで収集用のメモリを不必要に消費することを防止できる。
【０００６】
また、上記基本機能に加えて、以下の機能もある。
（４）トリガ検知機能
すでに述べたように、プロトコルアナライザはネットワークの不具合解析や状態把握に用いられるが、この場合、事前に設定した条件によりフレームを収集するタイミングを制御したいという要求がある。例えば、特定のフレームを検知すると収集を開始する、あるいは常時ＦＩＦＯ（Ｆｉｒｓｔ  Ｉｎ  Ｆｉｒｓｔ  Ｏｕｔ）でフレームを収集しておき、特定のフレームを検知したらそこで収集を停止するという制御をしたいという要求である。
【０００７】
ここで、「設定された条件に合致したことを検知する機能」をトリガ検知機能といい、このような収集のタイミングを制御する条件をトリガ検知条件という。
ところで、トリガ検知機能については以下のユーザニーズがある。
（１）フレームを取りこぼさない
（２）複雑なトリガ検知条件を設定したい
（３）トリガ検知条件を簡易に設定したい
【０００８】
これらの各ニーズについて以下、説明する。
（１）フレームを取りこぼさない
トリガ検知処理としては、ネットワーク上にフレームが流れるごとに設定された条件に合致しているかどうかを判断する。つまり、フレームが流れるたびに、１つづつのフレームについてトリガ検知の判断をしている。
毎回の判断は、次のフレームが流れる前までに完了しておかないと追いつかないこととなる。換言すると、フレーム検知としてのトリガ検知処理は少なくとも次のフレームがくるまでの一定時間内に判断結果を出す必要がある。もし、トリガ検知処理に時間を要し、判断終了前にネットワーク上に次のフレームが流れれば、このフレームのトリガ検知処理ができずに、フレームを取りこぼすことがある。ネットワークの解析というプロトコルアナライザの本来の目的から考えて、ネットワーク上のフレームを取りこぼすことは致命的な欠陥となる。
【０００９】
（２）複雑なトリガ検知条件を設定したい
ネットワークを解析するにあたっては、できるだけフレームを収集する条件を絞り込んで必要なものだけを収集したいというニーズがある。例えば、ある特定のビットパターンが検出されたら収集を開始するといった単一な条件だけでなく、複数の条件を組み合わせてトリガ検知をしたいということである。
【００１０】
例えば、１１０１というビットパターンを含んだフレームは頻繁にネットワークに流れており、これだけでは異常ではないが、この１１０１の後に１１１０というビットパターンのフレームが流れる場合は異常と考えられるようなケースがあるとする。この場合は、「１１０１のビットパターンフレームの後に１１１０というビットパターンのフレームが流れる」という２つの条件の組み合わせをトリガ条件とできると便利である。
【００１１】
また、フレーム内にアプリケーションとして意味を持つＩ／Ｏデータ（入出力データ）が含まれるような場合に、このＩ／Ｏデータに対して条件を設定できると便利な場合がある。
【００１２】
ところで、（１）の「フレームを取りこぼさない」ことを保証するためには、常に以下の式が満たされている必要がある。
【００１３】
Ｔ Ｆｒａｍｅ Ｉｎｔｅｒｖａｌ＞Ｔ Ｄｅｔｅｃｔ＋Ｔ Ｏｖｅｒｈｅａｄ
【００１４】
ここで、
Ｔ Ｆｒａｍｅ Ｉｎｔｅｒｖａｌ＝次のフレーム受信までの時間
Ｔ Ｄｅｔｅｃｔ＝受信したフレームのトリガ検知判断の処理時間
Ｔ Ｏｖｅｒｈｅａｄ＝フレームを受信してからトリガ検知判断処理が開始されるまでの時間＋トリガ検知判断処理が終了してから次のフ
レーム受信準備が完了するまでの時間
【００１５】
ところで、当然のことながら、トリガ検知条件を複雑にするにしたがい、検知処理判断に必要な処理時間Ｔ Ｄｅｔｅｃｔは増大する。従って、（１）の「フレームを取りこぼさない」という要求と（２）の「複雑なトリガ検知条件を設定したい」という要求は互いに相反する要求といえる。
【００１６】
（３）トリガ検知条件を簡易に設定したい
トリガ検知条件は簡易に設定できることが望ましい。特に、（２）の「複雑なトリガ検知条件を設定したい」という要求を満たすためには、できるだけ分かりやすく、容易にその条件が設定できることが望ましい。
【００１７】
以上がプロトコルアナライザ及びプロトコルアナライザで使用されるトリガ検知の説明であるが、次に、従来のトリガ検知方法を説明する。
【００１８】
すでに述べたように、トリガ検知処理は、ネットワークを流れるメッセージをリアルタイムに取得し、ユーザの設定した検知条件に一致するか否か判断する必要がある。同時に、メッセージの取りこぼしを起こさないため、次のメッセージを受信するまでの間に現在の受信処理を完了し、次の受信に備える必要がある。
【００１９】
すなわち、トリガ検知処理は限られた時間内で処理を完了しなければならない。
【００２０】
そこで、従来は、この時間的制約のため、シンプルな検知方法しか実現できなかった。
【００２１】
トリガ検知の具体的な方法としては、Ｍａｓｋ＆Ｍａｔｃｈという方式が採用される。Ｍａｓｋ＆Ｍａｔｃｈは受信したメッセージの一部をユーザが指定したマスク値でマスクし、マスク後の値がＭａｔｃｈ値と一致するかどうかで評価する方法である。
【００２２】
いま、これを図１２を参照しながら説明すると、受信データ（ａ）をＭａｓｋ値（ｂ）でマスクしてＭａｓｋ後の値（ｃ）を得、この値がＭａｔｃｈ値（ｄ）と一致するかどうか調べる。
【００２３】
例えば、１番目のデータでは、受信データ（ａ）は「００１１」、Ｍａｓｋ値（ｂ）は「００１１」なので、Ｍａｓｋ後の値（ｃ）は「００１１」となる。
【００２４】
なお、Ｍａｓｋ後の値（ｃ）は、受信データ（ａ）の「００１１」とＭａｓｋ値（ｂ）の「００１１」のそれぞれの同位ビットの乗算値として得られる。
【００２５】
ここで、１番目のデータでは、Ｍａｓｋ後の値（ｃ）は「００１１」であり、Ｍａｔｃｈ値（ｄ）も同じく「００１１」である。従って、１番目のデータ受信はトリガ検知となる。
【００２６】
図１３は、従来のメッセージ受信処理の概要を示すフローチャートである。この処理は、一例としてデバイスネットと呼ばれるネットワーク上をＣＡＮプロトコルと呼ばれるプロトコルでＣＡＮフレームが流れる場合の処理である。
ＣＡＮフレームは後述するように、１９ビットのＣＡＮヘッダフィールド、最大６４ビットのＤＡＴＡフィールド、２５ビットのＣＡＮトレイラフィールドより構成されている。
【００２７】
図１３においてメッセージ受信処理が開始されると（ステップ１００）、ＣＡＮフレームを内部バッファ（図示せず）に転送するという受信メッセージの処理１が行なわれる（ステップ１０２）。
【００２８】
次に、トリガ検知を実行するか否か調べられる（ステップ１０４）。これは、例えば図示しないパソコン画面上でトリガ検知ボタンが押されてトリガ検知モードに入っているか否か調べているもので、トリガ非検知モードでトリガ検知を実行しない場合は（ステップ１０４でＮＯ）、ステップ１０８に進むが、トリガ検知モードでトリガ検知を実行する場合は（ステップ１０４でＹＥＳ）、トリガ検知処理を実行する（ステップ１０６）。すなわち、Ｍａｓｋ＆Ｍａｔｃｈの処理を行なう。
【００２９】
次に、ステップ１０８では、受信メッセージの処理２を行ない、１フレームのメッセージ受信処理を終了する（ステップ１１０）。なお、ステップ１０８の受信メッセージの処理２では、ステップ１０６のＭａｓｋ＆Ｍａｔｃｈの処理でトリガ検知と判別された場合は、以後、キャプチャリング（受信フレームの取り込み）処理等を行なう。
【００３０】
次に、Ｍａｓｋ＆Ｍａｔｃｈによる上記ステップ１０６のトリガ検知処理の詳細を図１４のフローチャートを参照しながら説明する。
【００３１】
この処理では、トリガ検知が開始されると（ステップ１２０）、データ格納アドレスから期待データを取得する（ステップ１２２）。期待データを取得するとは、データ収集が開始されても、予め設定したアドレス値をもつものしか収集しない等のフィルタを設けているので、このフィルタを通過したデータだけを取り出すということである。これは、すでに述べたように、例えば、ノードやスレーブにアドレス番号を付しているので、特定のアドレス番号に着目して、そのアドレス番号を含むフレームだけを選択的に収集するということである。
【００３２】
次に、内部メモリよりＭａｓｋ値を取得し（ステップ１２４）、受信データをＭａｓｋ値にてマスクする（ステップ１２６）。
【００３３】
次に、内部メモリよりＭａｔｃｈ値を取得し（ステップ１２８）、マスク後のデータがＭａｔｃｈ値と一致するか否か調べる（ステップ１３０）。
【００３４】
ここで、マスク後のデータがＭａｔｃｈ値と一致しない場合は（ステップ１３０でＮＯ）、トリガ検知を終了する（ステップ１３４）。
【００３５】
一方、マスク後のデータがＭａｔｃｈ値と一致する場合は（ステップ１３０でＹＥＳ）、一致した場合の処理をして（ステップ１３２）、トリガ検知を終了する（ステップ１３４）。
【００３６】
なお、ステップ１３２の一致した場合の処理をするとは、トリガ検知でデータ収集を開始するとか、それまでやってきたデータ収集を終了するとか、一致したデータのみを収集するという処理をすることをいう。
【００３７】
【発明が解決しようとする課題】
ところで、すでに述べたように、ユーザのトリガ検知に関するニーズは、単一のＭａｓｋ＆Ｍａｔｃｈにとどまらず、もっと複雑なトリガ検知条件が設定できるようにすることであり、且つトリガ検知条件を簡易に設定できるようにすることである。
【００３８】
例えば、図１２の例では、１番目のデータは、受信データ（ａ）は「００１１」であり、Ｍａｓｋ値（ｂ）は「００１１」であり、Ｍａｓｋ後の値（ｃ）は「００１１」であり、Ｍａｔｃｈ値（ｄ）も同じく「００１１」である。従って、トリガ検知の条件を満たしている。
【００３９】
ところで、２番目のデータは、受信データ（ａ）は「１０１１」であり、Ｍａｓｋ値（ｂ）は「００１１」であり、Ｍａｓｋ後の値（ｃ）は「００１１」であり、Ｍａｓｋ値（ｂ）も同じく「００１１」である。従って、同じくトリガ検知の条件を満たしている。
【００４０】
つまり、受信データ（ａ）は異なるのに、同じＭａｓｋ値（ｂ）、同じＭａｔｃｈ値（ｄ）を用いてもトリガ検知の条件を満たしていると判断されている。
【００４１】
従って、図１２のトリガ検知条件では、１番目のデータがトリガ条件に一致しているのか、２番目のデータがトリガ条件に一致しているのか不明である。
【００４２】
そこで、複雑なトリガ検知条件が設定できるようにしたいというニーズがある。
【００４３】
従来は、このニーズをさまざまな条件が設定できる汎用のプログラムで満たしていた。しかし、さまざまな条件が設定できる汎用のプログラムで満たそうとすると、後述するように、純粋なトリガ検知処理であるＭａｓｋ＆Ｍａｔｃｈの部分以外に分岐処理等の冗長な処理が入り、受信処理が最小受信間隔以内に収まらないという問題点があった。
【００４４】
例えば、２通りのＭａｓｋ＆Ｍａｔｃｈの設定が可能で、１つ目のＭａｓｋ＆Ｍａｔｃｈを設定１、２つ目のＭａｓｋ＆Ｍａｔｃｈを設定２とすると、以下のような設定条件が可能である。
（１）設定１のみ
（２）設定２のみ
（３）設定１  ＡＮＤ  設定２
（４）設定１以外
（５）設定２以外
（６）設定１以外  ＡＮＤ  設定２
（７）設定１  ＡＮＤ  設定２以外
（８）設定１以外  ＡＮＤ  設定２以外
（９）設定１以外  ＯＲ  設定２
（１０）設定１  ＯＲ  設定２以外
（１１）設定１以外  ＯＲ  設定２以外
【００４５】
ここで、上記設定条件のうち、
（１）の設定１のみ、
（２）の設定２のみ、
（３）の設定１  ＡＮＤ  設定２、
の３つの設定条件が設定可能な汎用プログラムを利用してトリガ検知処理をする場合、その処理手順は図１５のフローチャートに示すようになる。
【００４６】
すなわち、トリガ検知が開始されると（ステップ１４０）、設定１のＭａｓｋ＆Ｍａｔｃｈの処理を行ない（ステップ１４２）、続いて、設定２のＭａｓｋ＆Ｍａｔｃｈの処理を行なう（ステップ１４４）。
【００４７】
ところで、図１５に示す検知処理プログラムは、上記（１），（２），（３）のいずれの設定条件にも対応できるよう汎用性が付与され、点線１７０で囲まれたプログラムを含んでいる。
すなわち、まず、トリガ設定条件の設定内容が調べられ、まず、トリガ設定条件は設定１のみか否か調べられる（ステップ１４６）。ここで、トリガ設定条件が設定１のみでない場合は（ステップ１４６でＮＯ）、ステップ１４８に進むが、トリガ設定条件が設定１のみの場合は（ステップ１４６でＹＥＳ）、設定１の評価を行なう（ステップ１５２）。すなわち、設定１のマスク値によるマスク後のデータが設定１のＭａｔｃｈ値と一致するか否かの評価が行なわれる。
【００４８】
次に、ステップ１４６で設定１のみでないと判別されて、ステップ１４８に進んだ場合は、トリガ設定条件は設定２のみか否か調べられる（ステップ１４８）。ここで、トリガ設定条件が設定２のみでない場合は（ステップ１４８でＮＯ）、ステップ１５０に進むが、トリガ設定条件が設定２のみの場合は（ステップ１４８でＹＥＳ）、設定２の評価を行なう（ステップ１５４）。すなわち、設定２のマスク値によるマスク後のデータが設定２のＭａｔｃｈ値と一致するか否かの評価が行なわれる。
【００４９】
次に、ステップ１４８で設定２のみでないと判別されて、ステップ１５０に進んだ場合は、トリガ設定条件は設定３の「設定１  ＡＮＤ  設定２」か否かが調べられる（ステップ１５０）。ここで、トリガ設定条件が設定３の「設定１  ＡＮＤ  設定２」でない場合は（ステップ１５０でＮＯ）、ステップ１５８に進むが、トリガ設定条件が設定３の「設定１  ＡＮＤ  設定２」の場合は（ステップ１５０でＹＥＳ）、「設定１  ＡＮＤ  設定２」の評価を行なう（ステップ１５６）。すなわち、設定１のマスク値によるマスク後のデータが設定１のＭａｔｃｈ値と一致し、且つ、設定２のマスク値によるマスク後のデータが設定２のＭａｔｃｈ値と一致するか否かの評価が行なわれる。
【００５０】
そして、続くステップ１５８では、評価結果が真か否か調べられ、評価結果が真でなければ（ステップ１５８でＮＯ）、トリガ検知を終了するが（ステップ１６２）、評価結果が真ならば（ステップ１５８でＹＥＳ）、トリガ検知時の処理を行ない（ステップ１６０）、トリガ検知を終了する（ステップ１６２）。
【００５１】
以上が、３つの設定条件が設定可能な場合のトリガ検知処理の処理手順である。
【００５２】
ところで、上記処理では、設定１，２のＭａｓｋ＆Ｍａｔｃｈの処理（ステップ１４２，１４４の処理）以外に、点線１７０で囲んだ処理を行なっているが、点線１７０で囲んだ処理は分岐処理を含んだ冗長な処理である。
【００５３】
例えば、設定条件が設定３「設定１  ＡＮＤ  設定２」の場合、点線１７０で囲んだ処理のうち、ステップ１５６以外の処理は不用な処理である。
【００５４】
つまり、トリガ設定条件を複雑にしたいが、この場合は、冗長な不要処理が増え、処理時間が延びて取りこぼしのおそれがある。
また、トリガ設定条件を複雑にすると、プログラムの表記が難しくなるという問題点があった。
【００５５】
そこで、本発明は、
（１）設定内容が複雑となっても、高速処理ができて取りこぼしがなく
（２）且つ、設定内容が複雑となっても、簡易な表記でプログラムが作成できるようにしたプロトコルアナライザ、トリガ検知装置、トリガ検知のためのプログラムが記録された記録媒体及びボードを提供することを目的とする。
【００５６】
【課題を解決するための手段】
上記目的を達成するため、本発明は、
ヘッダとデータフィールドを含むフレームが通信されるネットワークに接続され、所定のトリガ検知条件に基づいてネットワークを流れるフレームのうち必要なフレームを取り込むプロトコルアナライザにおいて、
Ｍａｓｋ＆Ｍａｔｃｈの使用とＩＤの指定とデータフィールドの使用との選択的組み合わせにより設定されたトリガ検知条件のそれぞれが論理表記に適した言語によって表記されたトリガ検知命令をコンパイルした結果が格納されるメモリと、
ネットワークを流れる上記フレームを受信する受信処理と、上記メモリから上記コンパイルされたトリガ検知命令を読み出して実行することにより、受信処理したフレームについてトリガ検知か否かを判別する判別処理と、判別処理の結果がトリガ検知である場合に処理するトリガ検知時処理と、を行うトリガ検知判別部と、
上記トリガ検知判別部のトリガ検知時処理に基づいて取り込んだフレームを記憶する記憶部と、
を有することを特徴とする。
【００５７】
ここで、ネットワークとは、伝送路を介してプログラマブルコントローラや各種デバイス（制御機器）が接続されてデータの送受信が行なわれるもので、実施形態では、デバイスネットというネットワーク１０が図１に示されている。
【００５８】
フレームとは、ネットワークで伝送されるデータの伝送単位をいい、実施形態では、ＣＡＮフレームと呼ばれるフレームが図４に示されている。
【００５９】
トリガ検知を説明すると、従来技術の欄でも説明したようにネットワークに関する不具合の原因を追求したり、ネットワークの状態を正確に把握するために、ネットワーク上を流れるフレームを収集し解析を行ないたい場合がある。この場合、特定のノードが出すフレームや、特定のビットパターンを持つフレームかどうか区別するために、トリガ検知条件を用いる。つまりトリガ検知条件とは収集しないフレームとそれ以外のフレームとを区別して判断するための判断条件である。フレーム収集するにあたっては事前にトリガ検知条件を設定し、この設定された条件に基づきトリガ検知処理を行なう実施形態では、図１に示したトリガ検知装置２０がトリガ検知処理を行なう。
【００６０】
また、本発明のプロトコルアナライザは、更にトリガ検知条件を設定するためのアプリケーション実行部を有し、
このアプリケーション実行部は、ユーザによって、Ｍａｓｋ＆Ｍａｔｃｈの使用とＩＤの指定とデータフィールドの使用とを選択的に組み合わせてトリガ検知条件が複数設定され、
上記言語をラダー言語とし、上記設定されたトリガ検知条件のそれぞれをラダー言語で表記されて上記トリガ検知命令が設定される
ことを特徴とする。
【００６１】
実施形態では、図７のトリガ条件設定画面（ダイアログボックス）を呼び出し、パソコン上の操作でラダー言語によるトリガ検知条件が設定される。そして、「ＯＫ」ボタンをクリックするとアプリケーション実行部２１（パソコン）でラダーニーモニックに変換され、共有メモリ４１にダウンロードされる。
【００６２】
そして、アプリケーション実行部２１（パソコン）側からモニタ開始の指示があると、共有メモリ４１からニーモニックで記述されたトリガ検知条件を呼び出しコンパイルする。コンパイルされたトリガ検知条件はバイナリ変換され、第１のＲＡＭ４４に格納される。
【００６３】
上記アプリケーション実行部は、
上記トリガ検知判別部へネットワーク監視開始とネットワーク監視終了とを管理し、
上記記憶部に記憶した取り込みフレームを読み出して表示するように構成することもできる。
【００６４】
また、上記アプリケーション実行部は、
上記トリガ検知条件を設定する際に、ダイアログボックスを提供するもので、
そのダイアログボックス上にてＭａｓｋ＆Ｍａｔｃｈの使用とＩＤの指定とデータフィールドの使用との選択的な組み合わせを設定可能とするように構成することもできる。
【００６７】
また、本発明のトリガ検知装置は、ネットワークを流れるヘッダとデータフィールドとを含むフレームが予め設定された所定のトリガ検知条件に合致するか否かを判別するトリガ検知装置において、
上記トリガ検知条件を、Ｍａｓｋ＆Ｍａｔｃｈの使用とＩＤの指定とデータフィールドの使用との選択的な組み合わせにより設定するとともに、設定したトリガ検知条件のそれぞれを論理表記に適した命令語によりトリガ検知命令を設定するトリガ検知命令設定手段と、
上記トリガ検知命令設定手段で設定されたトリガ検知命令をコンパイルするトリガ検知命令コンパイル手段と、
上記トリガ検知命令コンパイル手段によってコンパイルされたトリガ検知命令を格納されるメモリと、ネットワークを流れる上記フレームを受信する受信処理と、上記メモリのトリガ検知命令に基づいて上記受信処理したフレームが予め設定された所定のトリガ検知条件に合致するか否かを判別する判別処理と、判別処理の結果が条件合致である場合に処理するトリガ検知時処理と、を行うトリガ検知判別部と、
上記トリガ検知判別部のトリガ検知時処理に基づいて取り込んだフレームを記憶する記憶部と、
を有することを特徴とする。
【００６８】
本発明では、トリガ検知命令設定手段でトリガ検知条件をトリガ検知の論理表記に適した命令語で設定し、トリガ検知命令コンパイル手段でトリガ検知命令設定手段で設定されたトリガ検知命令をコンパイルする。
【００６９】
つまり、トリガ検知の都度、トリガ検知条件をトリガ検知の論理表記に適した命令語で設定し、設定されたトリガ検知命令をコンパイルする。
【００７０】
つまり、トリガ検知命令処理に応じてその都度コンパイルするので、従来のような汎用性を持たせたプログラムに比べて処理ステップが必要なものだけになる。そのぶん、処理時間が節約でき、従来に比べて複雑なトリガ条件を設定しても、フレームの取りこぼしのおそれがなくなる。
【００７１】
また、本発明のボードは、ネットワークを流れるヘッダとデータフィールドとを含むフレームが予め設定された所定のトリガ検知条件に合致するか否か判別するボードであって、
ホストに対して接続し、共有メモリを含むホストインタフェースと、
ネットワークを流れる上記フレームを取り込むネットインタフェースと、
Ｍａｓｋ＆Ｍａｔｃｈの使用とＩＤの指定とデータフィールドの使用との選択的な組み合わせにより設定された上記トリガ検知条件を論理表記に適した命令語により示したトリガ検知命令を上記共有メモリから読み出してコンパイルし、バイナリ命令に変換する変換手段と、
上記変換手段にて変換されたトリガ検知命令を格納するメモリと、
上記メモリに格納されたトリガ検知命令を実行し、上記ネットインタフェースから取り込んだフレームが予め設定された所定のトリガ検知条件に合致するか否かを判別する判別手段と、
上記判別手段の判別結果に基づいて所定のトリガ検知条件に合致するフレームを収集するフレーム収集部と、
を有することを特徴とする。
【００７２】
実施形態では、ボードは図３に示すアプリケーション実行部２１で、パソコンの拡張バスにつながれる増設ボードにあたる。また、ネットインタフェースは図３のネットインタフェース（ネットＩ／Ｆ）２４である。また、トリガ検知命令コンパイル手段及び判別手段はＭＰＵ４２に相当する。また、メモリは第１のＲＡＭ４４であり、フレーム収集部は共有メモリ４１である。
【００７３】
【発明の実施の形態】
以下、本発明に係るプロトコルアナライザ、トリガ検知装置、トリガ検知のためのプログラムが記録された記録媒体及びボードの実施の形態を図面に基づいて説明する。
【００７４】
図１は、本実施形態に係るトリガ検知装置が適用されたネットワーク構成を示すものである。
【００７５】
本実施形態では、ネットワーク１０はＣＡＮプロトコルと呼ばれるプロトコルを利用したデバイスネット（ＤｅｖｉｃｅＮｅｔ）と呼ばれるネットワークより構成されている。
【００７６】
デバイスネットは、ファクトリー・オートメーション等に適用される分散型のネットワークで、ネットワークには各種通信装置や制御機器が接続され、伝送路には各種通信装置や制御機器に対する入力情報（メッセージ）及び各種通信装置や制御機器からの出力情報（メッセージ）等がフレームとして流れている。
【００７７】
すなわち、ネットワーク１０には、例えば、通信装置１２−１（Ｓｌａｖｅ１）、通信装置１２−２（Ｓｌａｖｅ２）、通信装置１３（Ｓｃａｎｎｅｒ）、……が伝送路１１を介して接続され、伝送路１１には本実施形態に係わるトリガ検知装置２０が接続されている。具体的には、通信装置１２−１（Ｓｌａｖｅ１）、通信装置１２−２（Ｓｌａｖｅ２）は、プログラマブルコントローラ、デバイス、リモートＩ／Ｏ等である。
【００７８】
ここで、トリガ検知装置２０は、フレームを取りこぼさない、複雑なトリガ検知条件を設定したい等のユーザニーズを満たしつつ、ネットワークに流れるメッセージをネットワーク１０に負荷をかけることなくモニタするもので、プロトコルアナライザより構成できる。なお、プロトコルアナライザの機能等はすでに説明したので、重複した説明は省略する。
【００７９】
図２は、トリガ検知装置２０のシステム構成を示すもので、トリガ検知装置２０は、アプリケーション実行部２１と、アプリケーション実行部２１とホストインタフェース２２を介して接続されたトリガ検知実行ボード２３より構成され、トリガ検知実行ボード２３はネットインタフェース２４を介して伝送路１１と接続されている。
【００８０】
ここで、アプリケーション実行部２１はパソコン等より構成され、トリガ検知のためのトリガ検知条件が設定されるほか、ユーザの指示をトリガ検知実行ボード２３に伝え、トリガ検知実行ボード２３の実行結果をユーザに伝える。
【００８１】
なお、アプリケーション実行部２１では、具体的には、トリガ条件の設定、キャプチャフィルタの設定、ネットワーク監視開始命令の実行、ネットワーク監視終了命令の実行、キャプチャデータ（収集データ）の表示等の処理が行なわれるが、これらの詳細は後に述べる。
【００８２】
トリガ検知実行ボード２３は、アプリケーション実行部２１の指示のもとトリガ検知等を行なうボードで、ホストインタフェース２２を介してアプリケーション実行部２１の図示しないバススロット（拡張バススロット）に装着される。
なお、ボード２３がつながるのはＰＣＩバス（インテル社提唱の拡張バス規格）やＩＳＡバス（ＩＢＭ社提唱の拡張バス規格）と呼ばれる拡張バスである。以下、このようなバスを拡張バスという。
【００８３】
なお、トリガ検知実行ボード２３は、具体的には、アプリケーション実行部２１で設定されたトリガ条件のコンパイル処理やアプリケーション実行部２１からの指示に基づいてネットワーク監視、トリガ検知、特定のフレームの取り込み等の処理を行なうが、これらの詳細は後に述べる。
【００８４】
次に、トリガ検知実行ボード２３の構成を図３を参照しながら説明する。
【００８５】
トリガ検知実行ボード２３は、拡張バスインタフェース（拡張バス  Ｉ／Ｆ）４０、共有メモリ４１、ＭＰＵ４２、ＲＯＭ４３、第１のＲＡＭ４４、第２のＲＡＭ４５、ＣＡＮ制御部４６、トランシーバー４７、ネットインタフェース（ネットＩ／Ｆ）２４より構成されている。
【００８６】
ここで、拡張バスインタフェース（拡張バス  Ｉ／Ｆ）４０は、アプリケーション実行部２１の図示しない拡張バスバススロットに装着されるもので、アプリケーション実行部２１とトリガ検知実行ボード２３とのインタフェースをとる。
【００８７】
共有メモリ４１は、アプリケーション実行部２１とトリガ検知実行ボード２３の共有メモリとなるもので、アプリケーション実行部２１で設定したトリガ検知命令の書き込み等、あるいはトリガ検知実行ボード２３で収集したデータのバッファリング等が行なわれる。
【００８８】
なお、拡張バスインタフェース（拡張バス  Ｉ／Ｆ）４０と共有メモリ４１より図２に示したホストインタフェース２２が構成されている。
【００８９】
ＭＰＵ４２はトリガ検知実行ボード２３全体を統括制御するもので、共有メモリ４１に書き込まれたトリガ検知命令をアプリケーション実行部２１の指示のもとコンパイルして第１のＲＡＭ４４に格納する処理、アプリケーション実行部２１の指示のもとネットワーク監視、トリガ検知、特定のフレームの取り込み処理等を行なう。
【００９０】
ＲＯＭ４３は、ＭＰＵ４２で実行されるシステムプログラムが格納される。
【００９１】
第１のＲＡＭ４４は、アプリケーション実行部２１によって共有メモリ４１に書き込まれたトリガ検知命令がＭＰＵ４２によってコンパイルされたとき、コンパイルされたトリガ検知命令を格納する。
【００９２】
第２のＲＡＭ４５はトリガ検知のため収集されたデータが一時的に格納されるメモリで、この第２のＲＡＭ４５への格納時、格納データのトリガ検知が行なわれる。この第２のＲＡＭ４５にデータを取り込むに際しては、データのアドレス等に基づいたフィルタリング処理が行なわれ、共有メモリ４１のバッファが無駄な情報で埋められることが防止されている。なお、第２のＲＡＭ４５には１つのデータのみ取り込まれ、必要なデータは共有メモリのバッファに格納され、不必要なデータはそのまま破棄される。なお、ＲＡＭ４４，４５は１つのＲＡＭで構成し、２つの領域に分割してもよい。
【００９３】
ＣＡＮ制御部４６は、ディジタルデータに変換された入力データからＣＡＮフレームを取り出すものである。
【００９４】
トランシーバー４７は、ＣＡＮ制御部４６からの信号に基づき伝送路１１上に電圧を発生させるものである。
【００９５】
ネットインタフェース（ネットＩ／Ｆ）２４は、伝送路１１とトリガ検知実行ボード２３とのインタフェースをとるものである。
【００９６】
次に、図１に示したネットワーク１０の伝送路１１を流れるデバイスネットのメッセージフォーマットについて説明する。
【００９７】
デバイスネットはＣＡＮプロトコルのフレーム構造を利用し、フレーム・ヘッダの中の１１ビット（ＣＡＮ  Ｉｄｅｎｔｉｆｉｅｒ  Ｂｉｔｓ）とデータフィールドにデバイスネットとしての意味を持たせている。
【００９８】
図４は、ＣＡＮのフレーム構成を示すものであるが、ＣＡＮフレーム３０は、１９ビットのＣＡＮ  ＨＥＡＤＥＲ（３１）、０〜６４ビットのＤＡＴＡ  ＦＩＥＬＤ（３２）、２５ビットのＣＡＮ  ＴＲＡＩＬＥＲ（３３）より構成されている。
【００９９】
また、図５は、図４に示したＣＡＮ  ＨＥＡＤＥＲ３１の詳細を示すものであるが、１ビットのＳｔａｒｔ  ｏｆ  Ｆｒａｍｅ（３１−１）、１１ビットのＣＡＮ  Ｉｄｅｎｔｉｆｉｅｒ（３１−２）、１ビットのＲＴＲ  Ｂｉｔ（３１−３）、６ビットのＣｏｎｔｒｏｌ（３１−４）より構成されている。
【０１００】
ところで、上記の如き、ＣＡＮフレーム構成において、ＣＡＮフレームの受信間隔は、ＣＡＮフレーム間のインターフレームスペースが最小の３ビットで、ＣＡＮフレーム３０のＤＡＴＡ  ＦＩＥＬＤ（３２）が０ビットのとき最小となる。
【０１０１】
このとき、ビット長は、以下のようになる。
【０１０２】
ＣＡＮ  ＨＥＡＤＥＲ＋ＤＡＴＡ  ＦＩＥＬＤ＋ＣＡＮ  ＴＲＡＩＬＥＲ
＋インターフレームスペース
＝１９＋０＋２５＋３
＝４７（ビット）
【０１０３】
従って、デバイスネットで最速の通信速度である５００Ｋｂｐｓを使用した場合、
４７÷５００，０００＝０．００００９４（ｓｅｃ）
となり、
９４μｓｅｃが最小受信間隔となる。
【０１０４】
また、トリガ検知処理の最長処理時間は以下の式を満足するものでなければならない。
【０１０５】
最小受信間隔（９４μｓｅｃ）＞受信処理＋受信データ転送処理＋トリガ検知処理
【０１０６】
上記の如き本実施形態の構成及び上記の如き条件のもと、本実施形態では以下のようにトリガ検知を行なっている。
【０１０７】
まず、図６のフローチャートを参照しながら、本実施形態におけるトリガ検知の概要を説明する。
【０１０８】
ところで、本実施形態による図６の処理と図１５に示した従来例の処理の差異は、図１５における点線１７０内の処理が図６ではステップ２０６の処理に置き換わったことと、ステップ２０６の処理の前段にアプリケーション実行部２１の処理であるステップ２１４、２１６の処理が追加されたことである。
【０１０９】
従って、ステップ２００（図１５のステップ１４０と同じ）、ステップ２０２（図１５のステップ１４２と同じ）、ステップ２０４（図１５のステップ１４４と同じ）、ステップ２０８（図１５のステップ１５８と同じ）、ステップ２１０（図１５のステップ１６０と同じ）、ステップ２１２（図１５のステップ１６２と同じ）の処理の説明は図１５の説明に譲り、重複した説明は省略する。
【０１１０】
図６において、ステップ２１４、２１６の処理はパソコン等で構成されるアプリケーション実行部２１で行なわれる処理であり、ステップ２００〜２１２の処理はトリガ検知実行ボード２３で行なわれる処理である。
【０１１１】
まず、アプリケーション実行部２１で行なわれるステップ２１４の処理は、トリガ検知のためのプログラムが記録された記録媒体のプログラムに基づいて、ユーザがトリガ検知命令を設定する処理である。具体的には後述する図８に示すダイアログボックスがユーザに提供され、このダイアログボックス上で設定される。
図８では、設定１と設定２の２種類の条件設定を可能としている。そして、各設定では、ＣＡＮ  ＩＤのＭａｓｋ＆Ｍａｔｃｈ指定とデータフィールドのＭａｔｃｈｉｎｇ指定を可能としている。なお、図８では、「複数指定」が選択されている。
ここでは、トリガ検知の論理表記に適した言語を採用することにより、複雑なトリガ設定を簡易な表記方法で表現することが可能である。このような言語として例えばラダー言語がある。
【０１１２】
次に、ステップ２１４で設定された簡易な言語で表記されたトリガ検知命令をトリガ検知実行ボード２３の共有メモリ４１（ホストインタフェース２２を構成する）にダウンロードする（ステップ２１６）。例えばステップ２１４でトリガ検知命令がラダー言語で表記されている場合、ラダーニーモニックで書き込まれる。
【０１１３】
トリガ検知実行ボード２３のＭＰＵ４２はこれをコンパイルし、さらにバイナリ命令に変換して第１のＲＡＭ４４に格納する。
【０１１４】
トリガ検知実行ボード２３は第１のＲＡＭ４４に格納されたトリガ検知命令に基づいてトリガ検知を行なう（ステップ２０６）。
【０１１５】
すでに述べたように、ステップ２１４で設定されるトリガ検知命令は、高度なトリガ検知の論理表記に適した、且つ簡易な言語を採用でき、複雑なトリガ設定を簡易な表記方法で表現できるようにしている。
【０１１６】
つまり、新たなトリガ検知のたびに、最も適したトリガ検知条件を設定しコンパイルする。例えば、図１５において、設定３の検知条件でトリガ検知するのであったら、点線１７０内でステップ１５６の処理だけ含むプログラムを作る。従って、図１５の点線１７０の処理のように分岐のある冗長な処理はなくなり、複雑なトリガ検知処理を短時間で行なえるようになる。
【０１１７】
図７には、図６のステップ２１４で設定されるトリガ命令の設定にあたり、トリガ検知の論理表記に簡易な言語を採用した表記例が示されており、２通りのＭａｓｋ＆Ｍａｔｃｈの設定によりトリガ検知する場合の設定内容が示されている。
図７において、（ａ）にはラダー表記が示されており、（ｂ）にはニーモニック表記が示されている。
【０１１８】
すなわち、「設定１」は「Ｔｒｉｇｇｅｒ１の条件（Ｍａｓｋ＆Ｍａｔｃｈ）に一致し、且つデータフレームのオフセット２バイト目のデータが０ｘ４１または０ｘ４０のとき」である。
【０１１９】
また、「設定２」は「Ｔｒｉｇｇｅｒ２の条件（Ｍａｓｋ＆Ｍａｔｃｈ）の一致するとき」である。
【０１２０】
ここで、「設定１」又は「設定２」のどちらか一方の条件が成立したときトリガ検知と判断する。
【０１２１】
本実施形態では、これらの設定条件をトリガ検知の論理表記に適した言語で表記する。
【０１２２】
次に、本実施形態に係わるトリガ検知装置２０の動作をアプリケーション実行部２１における動作とトリガ検知実行ボード２３における動作に分けてそれぞれ説明する。
【０１２３】
アプリケーション実行部２１における動作
（１）トリガの設定
（イ）この処理では、まず、トリガ設定画面（ダイアログボックス）をユーザに提供する。図８には、この画面を利用してトリガを設定した場合の画面例が示されている。
【０１２４】
この画面は、図７の設定条件で画面設定した場合の画面例である。
【０１２５】
「設定１」は「Ｔｒｉｇｇｅｒ１の条件（Ｍａｓｋ＆Ｍａｔｃｈ）に一致し、且つデータフレーム（データフィールド）のデータが設定値のとき」である。
【０１２６】
また、「設定２」は「Ｔｒｉｇｇｅｒ２の条件（Ｍａｓｋ＆Ｍａｔｃｈ）の一致するとき」である。
【０１２７】
ここで、「設定１」又は「設定２」のどちらか一方の条件が成立したとき（ＯＲ）トリガ検知と判断する。
【０１２８】
なお、上記設定例は、「設定１  ＯＲ  設定２」であるが、設定１と設定２の組み合わせには以下のものがある。
（１）設定１のみ
（２）設定２のみ
（３）設定１  ＡＮＤ  設定２
（４）設定１  ＯＲ  設定２
（５）設定１以外
（６）設定２以外
（７）設定１以外  ＡＮＤ  設定２
（８）設定１  ＡＮＤ  設定２以外
（９）設定１以外  ＡＮＤ  設定２以外
（１０）設定１以外  ＯＲ  設定２
（１１）設定１  ＯＲ  設定２以外
（１２）設定１以外  ＯＲ  設定２以外
（１３）設定１以外  ＴＨＥＮ  設定２
（１４）設定１  ＴＨＥＮ  設定２以外
（１５）設定１以外  ＴＨＥＮ  設定２以外
【０１２９】
ここで、「設定１  ＴＨＥＮ  設定２」とは、設定１に一致するメッセージを検知したら、以降設定２に一致するメッセージを待つ。そして、設定２の条件に一致するメッセージを受信したときトリガ条件が成立したと判断する、という意味である。
【０１３０】
（ロ）次に、ユーザが図８の画面上で設定した設定内容をホストインタフェース２２の共有メモリ４１にダウンロードする。
【０１３１】
この処理は、図８の画面上でトリガ条件が設定されると「ＯＫ」ボタンをクリックすることによってアプリケーション実行部２１側においてラダーニーモニックが自動生成され、この自動生成されたラダーニーモニックが共有メモリ４１にダウンロードされることによって行なわれる。
【０１３２】
（ハ）次に、ホストインタフェース２２を介し、ＭＰＵ４２に対して、共有メモリ４１に書き込まれたトリガ検知の設定内容をコンパイルして第１のＲＡＭ４４に格納するよう指示する。
【０１３３】
（２）キャプチャフィルタの設定
（イ）この処理では、まず、キャプチャフィルタ設定画面（ダイアログボックス）をユーザに提供する。図９には、キャプチャフィルタ設定のための画面例が示されている。キャプチャフィルタは、取り込んだフレームを全てトリガ検知するの対象とするのではなく、予めトリガ検知の対象となるフレームを絞り込むために設ける。例えばフレームのアドレスが特定のアドレスのものだけ通過させる。（ロ）ユーザが画面上で設定した設定内容は、ホストインタフェース２２の共有メモリ４１にラダーニーモニックで書き込む。なお、すでに述べたように、このフィルタを通過したデータのみ第２のＲＡＭ４５に格納される。
【０１３４】
（３）ネットワーク監視開始命令
（イ）ネットワーク監視開始のボタンを画面上でユーザに提供する。
（ロ）ユーザがボタンを押すと、ホストインタフェース２２を介してＭＰＵ４２に対してネットワーク監視開始を指示する。
【０１３５】
（４）ネットワーク監視終了命令
（イ）ネットワーク監視終了のボタンを画面上でユーザに提供する。
（ロ）ユーザがボタンを押すと、ホストインタフェース２２を介してＭＰＵ４２に対してネットワーク監視終了を指示する。
【０１３６】
（５）キャプチャデータ表示
トリガ検知実行ボード２３からネットワーク監視終了通知を受け、トリガ検知実行ボード２３がホストインタフェース２２の共有メモリ４１に書き込んでいるキャプチャデータを読み出し、画面でユーザに提供する。図１０にこのときの表示例を示す。
【０１３７】
トリガ検知実行ボード２３における動作
（１）トリガ設定
（イ）アプリケーション実行部２１からトリガ検知命令のコンパイル命令を受け取る。
（ロ）これによってホストインタフェース２２の共有メモリ４１に書き込まれているラダーニーモニックのトリガ検知命令を読み出し、ＭＰＵ４２が実行可能な命令セットを生成する（コンパイル処理）。
（ハ）次に、バイナリ命令に変換し、第１のＲＡＭ４４に書きこむ。
【０１３８】
（２）ネットワーク監視、トリガ検知、フレーム取り込み
（イ）アプリケーション実行部２１からネットワーク監視開始命令を受け取る。（ロ）ネットワーク監視を開始する。
（ハ）設定内容に従ってトリガ検知処理を行なう。設定には以下のようなものが可能である。これらの設定はアプリケーション実行部２１においてユーザが指定する。
【０１３９】
・設定例１  トリガ条件に一致したフレームを検知してからフレームの取り込みを開始する。取り込んだフレームは共有メモリ４１にバッファリングするが、共有メモリ４１が一杯になったところでフレーム取り込み処理を終了し、アプリケーション実行部２１に監視終了通知を行なう。
【０１４０】
・設定例２  アプリケーション実行部２１からネットワーク監視命令を受け取ると直ちに共有メモリ４１へのフレーム取り込みを開始し、トリガ条件に一致するフレームを検知したところで取り込みを終了し、アプリケーション実行部２１に監視終了通知を行なう。
【０１４１】
設定例２では、トリガ条件に一致する前にバッファが一杯になった場合は、ＦＩＦＯ（Ｆｉｒｓｔ  Ｉｎ  Ｆｉｒｓｔ  Ｏｕｔ）により、最新のデータが残る形式で取り込みを続け、やはりトリガ条件に一致したところで取り込みを終了する。
【０１４２】
なお、本実施形態では、ネットワークの監視が終了する原因には以下の３つの場合がある。
（１）アプリケーション実行部２１からネットワーク監視終了命令を受けた場合（２）上記設定１の場合で、トリガ条件に一致したフレームを検知してからフレームの取り込みを開始し、共有メモリ４１が一杯になったとき
（３）上記設定例２の場合で、トリガ条件に一致するフレームを検知したとき
【０１４３】
（ニ）設定２の場合には、フレーム取り込みの際には、アプリケーション実行部２１によりホストインタフェース２２の共有メモリ４１に設定されているフィルタ条件に一致するフレームのみを選択的に取り込み、バッファに格納する。格納バッファは、ホストインタフェース２２の共有メモリ４１を使用する。
【０１４４】
図１１は、トリガ検知実行ボード２３におけメッセージ受信処理とその処理時間を示すフローチャートである。
【０１４５】
この処理では、メッセージ受信処理が開始されると（ステップ２２０）、データの転送等の受信処理が行なわれる（ステップ２２２）。
【０１４６】
次に、設定１のＭａｓｋ＆Ｍａｔｃｈの処理を行ない（ステップ２２４）、続いて、設定２のＭａｓｋ＆Ｍａｔｃｈの処理を行なう（ステップ２２６）。
【０１４７】
続いて、第１のＲＡＭ４４に格納されたトリガ検知命令に基づきトリガ検知命令を実行する（ステップ２２８）。
【０１４８】
続いてトリガ検知か否かが調べられ（ステップ２３０）、トリガ検知でない場合は（ステップ２３０でＮＯ）、ステップ２３４に進むが、トリガ検知の場合は（ステップ２３０でＹＥＳ）、トリガ検知時の処理を行なう（ステップ２３２）。
【０１４９】
そして、続くステップ２３４では、メッセージキャプチャ等の受信処理が行なわれ、トリガ検知を終了する（ステップ２３６）。
【０１５０】
ところで、この処理は、すでに述べたように、９４μｓｅｃ以内に行なう必要があるが、ＭＰＵ４２の動作クロックが１６Ｍｈｚの場合ステップ２２８におけるトリガ検知命令の実行処理時間は約４μｓｅｃである。これは、すでに述べたように、例えば、図１５において、設定３のトリガ検知条件でトリガ検知する場合、点線１７０内のステップ１５６の処理のみ行なえばよいからである。
【０１５１】
従って、フレームを取りこぼすことなく、複雑な検知条件を設定できる等の効果を奏する。
【０１５２】
以上説明したように、本実施形態では、アプリケーション実行部２１で都度トリガ検知条件を設定し、設定したトリガ検知条件は、ホストインタフェース２２の共有メモリ４１に書き込む。次に、トリガ検知実行ボード２３はアプリケーション実行部２１からトリガ命令のコンパイル命令を受け取ると、ホストインタフェース２２の共有メモリ４１に書き込まれているトリガ命令を読み出し、ＭＰＵ４２が実行可能な命令セットを生成（コンパイル処理）、第１のＲＡＭ４４に書き込むようにした。
【０１５３】
従って、その時々のトリガ検知の態様に応じて柔軟なトリガ検知条件を設定でき、図１５に示した従来例のような汎用的なロジックを採用した場合の冗長な処理がなくなる。従って、複雑なトリガ条件の設定が可能となる。
【０１５４】
また、トリガ検知命令を簡易な表記方法で表現できるので、コンパイル処理を簡単に行なうことができる。
【０１５５】
また、図１５の点線１７０に示す如き分岐命令が存在しないために、複雑な条件の場合でも高速に判定処理が行なえる。
【０１５６】
【発明の効果】
以上説明したように、本発明では、ネットワークを流れるフレームが予め設定された所定のトリガ検知条件に合致するか否か判別するトリガ検知装置において、上記トリガ検知条件をトリガ検知の論理表現に適した命令語で設定するトリガ検知命令設定手段と、上記トリガ検知命令設定手段で設定されたトリガ検知命令をコンパイルするトリガ検知命令コンパイル手段と、を有し、上記トリガ検知命令コンパイル手段でコンパイルされたトリガ検知命令に基づいてネットワークを流れるフレームが予め設定された所定のトリガ検知条件に合致するか否か判別するようにしたので、その時々のトリガ検知の態様に応じて柔軟なトリガ検知条件を設定でき、複雑なトリガ条件の設定が可能となる。
また、従来では、取りこぼしするおそれのあるような複雑な検知条件の設定をしても、高速処理するので、取りこぼしがない。
【図面の簡単な説明】
【図１】本発明に係るトリガ検知装置が適用されたネットワーク構成を示す図。
【図２】図１に示したトリガ検知装置２０のシステム構成を示す図。
【図３】図２に示したトリガ検知実行ボード２３の構成を示すブロック図。
【図４】ＣＡＮのフレーム構成を示す図。
【図５】図４に示したＣＡＮ  ＨＥＡＤＥＲ３１の詳細を示す図。
【図６】本実施形態におけるトリガ検知装置の概要を説明する図。
【図７】図６のステップ２１４で設定されるトリガ命令の設定にあたり、２通りのＭａｓｋ＆Ｍａｔｃｈの設定によりトリガ検知する場合の設定内容を示す図。
【図８】トリガ設定画面（ダイアログ）をユーザに提供する場合の画面例。
【図９】キャプチャフィルタ設定画面（ダイアログ）をユーザに提供する場合の画面例。
【図１０】トリガ検知実行ボード２３からネットワーク監視終了通知を受け、トリガ検知実行ボード２３がホストインタフェース２２の共有メモリ４１に書き込んでいるキャプチャデータを読み出し、画面でユーザに提供する場合の表示例。
【図１１】トリガ検知実行ボード２３における処理手順とその処理時間を示すフローチャート。
【図１２】Ｍａｓｋ＆Ｍａｔｃｈでトリガ検知する場合の説明図。
【図１３】従来のメッセージ受信処理の概要を示すフローチャート。
【図１４】Ｍａｓｋ＆Ｍａｔｃｈでトリガ検知する場合の処理手順を示すフローチャート。
【図１５】ユーザのニーズを汎用のプログラムで満たそうとする場合、純粋なトリガ検知処理であるＭａｓｋ＆Ｍａｔｃｈの部分以外に分岐処理等の冗長な処理が入り（例えば、図１５の点線１７０内の処理）、受信処理が最小受信間隔以内に収まらないことを説明するための説明図。
【符号の説明】
１０  ネットワーク
１１  伝送路
１２−１、１２−２  通信装置
１３  通信装置
２０  トリガ検知装置
２１  アプリケーション実行部
２２  ホストインタフェース
２３  トリガ検知実行ボード
２４  ネットインタフェース
４０  拡張バスインタフェース（拡張バス  Ｉ／Ｆ）
４１  共有メモリ
４２  ＭＰＵ
４３  ＲＯＭ
４４  第１のＲＡＭ
４５  第２のＲＡＭ
４６  ＣＡＮ制御部
４７  トランシーバー
【図１】
0003548911.tif 000002
【図２】
0003548911.tif 000003
【図３】
0003548911.tif 000004
【図４】
0003548911.tif 000005
【図５】
0003548911.tif 000006
【図６】
0003548911.tif 000007
【図７】
0003548911.tif 000008
【図８】
0003548911.tif 000009
【図９】
0003548911.tif 000010
【図１０】
0003548911.tif 000011
【図１１】
0003548911.tif 000012
【図１２】
0003548911.tif 000013
【図１３】
0003548911.tif 000014
【図１４】
0003548911.tif 000015
【図１５】
0003548911.tif 000016