JP2018197745A - コンピューティング装置、物理的な入力信号を解釈する方法及びそのためのコンピュータ・プログラム - Google Patents

Abstract

【課題】物理的な入力信号のプロトコルに関係なく、構文木を用いて、物理的な入力信号をビットストリームに変換する。【解決手段】プロトコル宣言３０内に宣言型言語で書かれたビットストリーム、イベン及びフィールド定義１０２、２０２及び３０２を用いて、試験測定システム中のパーサ４０は、構文木６０をコンパイルでき、これは、物理的な入力信号５０を適切なビットストリーム７０に自動的に変換する。プロトコル宣言３０内の宣言型言語定義１０２、２０２及び３０２は、安全でない関数を書くことなく、メモリにアクセルする必要なく、又は、もっと複雑な言語コードをデバッグすることなく、カスタム又は標準プロトコル・ルールを複数又は任意のプロトコルに関して書くことを可能にする。【選択図】図２

Description

本発明は、物理的な入力信号のプロトコルに関係なく、構文木を用いて、物理的な入力信号をビットストリームへ変換するコンピューティング装置、方法及びコンピュータ・プログラムに関する。

ネットワーク通信では、物理媒体を介して受信された全てのデータは、最初に、その物理的レイヤ上のライン・コーディングからデコードされ、次いで、トランスポート、セッション又はアプリケーション・レイヤのような、より高いレベルのレイヤでの使用のために適切に変換されたビットストリームを出力するのに、そのデータ・リンク及びネットワーク・レイヤにおける特定のネットワーク・プロトコルに基づいて、更にデコードされなければならない。このデコード処理は、試験測定装置において、装置によって出会った各プロトコル形式に関して特別に記述されたプロトコル・デコーダとして、これまで実装されてきた。

特開２０１１−１１７９６７号公報 特開２０１６−０３５４６０号公報

しかし、Ｃ又はＰｙｔｈｏｎのような従来のチューリング完全言語を、プロトコル・デコーダに書いて用いるのは、時間がかかり、エラーが発生しがちである。プロトコル記述言語において正規表現を用いる問題を解決しようとする従来の試みは、多数の困難に遭遇してきた。例えば、いくつかのプロトコルの仕様は、従来の宣言型言語で表現するには、あまりに複雑過ぎる。加えて、従来の宣言型言語の文法は、最初のパケット・フレーム化（フレーミング）ステップのような、必要なプロトコルの仕様の全てを記述するには不十分なことがある。こうした理由のために、物理的な信号及びビットストリームのデコード処理は、典型的には、イーサネット・トラフィックのような、同様なプロトコル・スイートのファミリーに限定されている。同様に、プロトコル・アナライザは、特定のプロトコル用に設計及びコード化されており、これによって、その能力が、入力される多様な信号に渡って動作する柔軟性に関して制限されている。

以下では、本願で開示される技術の説明に有益な実施例が提示される。この技術の実施形態は、以下で記述する実施例の１つ以上及び任意の組み合わせを含んでいても良い。

実施例１としては、試験及び測定に適したコンピューティング装置があり、ライン・コード化物理的信号を受ける物理的チャンネル入力部と、宣言型言語定義から生成された構文木（syntax tree）を記憶するメモリと、該メモリと動作可能に結合され、上記構文木にアクセスし、上記ライン・コード化物理的信号から時間及びエッジ・データを抽出し、上記構文木の状態に基づいて抽出された上記時間及びエッジ・データを用いてビットストリームに関するビット値を生成するよう構成されるプロセッサとを具えている。

実施例２としては、実施例１の態様があり、このとき、上記プロセッサが、更に、上記宣言型言語定義内のイベント開始及び終了定義に基づいて上記ビットストリームから時間マーカを抽出し、抽出された上記時間マーカに基づいて上記構文木を用いて上記ビットストリームについてのパケット・フレームを生成するように構成される。

実施例３としては、実施例１及び２の態様があり、このとき、上記プロセッサが、更に、上記宣言型言語定義内のフィールド定義に基づいて、生成された上記パケット・フレーム内にフィールドをマッピングし、マッピングされた上記フィールドに基づいて、上記構文木を用いて上記ビットストリームについてのパケットを生成するよう構成される。

実施例４としては、実施例１、及び３の態様があり、このとき、上記プロセッサが、更に、エラー対処定義に基づいて上記構文木を用いてパケットを検証するよう構成される。

実施例５としては、実施例１及び２の態様があり、このとき、上記イベント開始及び終了定義は、フィールド・デバイス・アクセス及びデバイス記述言語ライブラリから得られる。

実施例６としては、実施例１の態様があり、このとき、上記宣言型言語定義は、ライン・コード・エンコーディング・ライブラリから得られる。

実施例７としては、実施例１の態様があり、このとき、上記プロセッサが、更に、上記宣言型言語定義からの上記構文木をコンパイルするよう構成される。

実施例８としては、実施例１の態様があり、このとき、上記構文木が第１メモリに記憶され、上記宣言型言語定義が第２メモリに記憶される。

実施例９としては、構文木を用いて物理的な入力信号を解釈する方法があり、宣言型言語定義を読み出す処理と、上記宣言型言語定義に基づいて上記構文木をコンパイルする処理と、上記構文木のノードを用いて上記物理的な入力信号のライン・コード・エンコーディングをデコードすることによって、上記物理的な入力信号をビットストリームへ変換する処理とを具えている。

実施例１０としては、実施例９の態様があり、イベント開始及び終了定義に基づいて、上記構文木を用いて上記ビットストリームについてのパケット・フレームを生成する処理を更に具えている。

実施例１１としては、実施例９及び１０の態様があり、このとき、フィールド定義に基づいて、上記構文木を用いて上記ビットストリームについてのパケットを生成する処理を更に具えている。

実施例１２としては、実施例９、１０及び１１の態様があり、このとき、エラー対処定義に基づいて上記構文木を用いてパケットを検証する処理を更に具えている。

実施例１３としては、実施例９、１０及び１１の態様があり、このとき、メディア・ファイルを出力するため、トークン交換を用いて上記ビットストリームのパケットからペイロードを抽出する処理を更に具えている。

実施例１４としては、実施例９及び１０の態様があり、このとき、上記イベント開始及び終了定義は、フィールド・デバイス・アクセス及びデバイス記述言語ライブラリから得られる。

実施例１５としては、実施例９の態様があり、このとき、上記宣言型言語定義は、ライン・コード・エンコーディング・ライブラリから得られる。

実施例１６としては、コンピュータ・プログラムがあり、これは、試験及び測定に適したコンピューティング装置中のプロセッサで実行されたときに、上記コンピューティング装置に、ビットストリーム定義、イベント定義及びフィールド定義の中の１つ以上を含むプロトコル宣言に基づいて構文木をコンパイルさせ、物理的な信号を受けるようにさせ、上記構文木を用いて上記物理的な信号をビットストリームにデコードさせる。

実施例１７としては、実施例１６の態様があり、このとき、更に、上記ビットストリーム定義を供給するために、上記コンピューティング装置に、ライン・コード・エンコーディング・ライブラリを利用させる。

実施例１８としては、実施例１６の態様があり、このとき、更に、上記イベント定義を供給するために、上記コンピューティング装置に、フィールド・デバイス・アクセス及びデバイス記述言語ライブラリを利用させる。

実施例１９としては、実施例１６の態様があり、このとき、更に、上記フィールド定義を供給するために、上記コンピューティング装置に、フィールド・デバイス・アクセス及びデバイス記述言語ライブラリを利用させる。

実施例２０としては、実施例１６の態様があり、このとき、上記プロトコル宣言は、標準的なネットワーク・プロトコルに基づいている。

実施例２１としては、実施例１６の態様があり、このとき、上記プロトコル宣言は、カスタム・ネットワーク・プロトコルに基づいている。

実施例２２としては、実施例１６の態様があり、このとき、更に、メディア・ファイルを出力するために、上記コンピューティング装置に、トークン交換を用いて上記ビットストリームのパケットからペイロードを抽出させる。

図１は、本発明の実施形態による例示的な試験測定システムのブロック図である。 図２は、プロトコル宣言に基づいてコンパイルされた構文木を用いて、物理的な入力信号をパケット化ビットストリームに変換する本発明の実施形態による方法のブロック図である。 図３は、本発明の実施形態による、３つのステージを有する例示的な構文木のデコード処理のブロック図である。 図４は、プロトコル宣言からの異なるビットストリーム定義を用いて、例示的な構文木デコード処理の第１ステージにおいて、物理的な入力信号の未加工のビットストリームへの変換を示す、本発明の実施形態による時間プロットである。 図５は、イベント検索及びフィールド・マッピング・ステージ中に、パケット・フレーミング及びフィールド・データを抽出するのに、ＬＩＮプロトコルに基づくプロトコル宣言を利用する、本発明の実施形態による例示的な構文木デコード処理のブロック図である。 図６は、複数の物理的な入力信号をフレーム化パケット・ビットストリーム・データに変換するのに、Ｉ２Ｃプロトコルに基づくプロトコル宣言を利用する、本発明の実施形態による例示的な構文木デコード処理のブロック図である。 図７は、本発明の実施形態による例示的な処理及びデータ・フローのブロック図である。

本説明は、例えば、抽象構文木（abstract syntax tree）のようなコンパイラで生成された構文木（syntax tree）用いて、任意の通信又はネットワーク・プロトコルによる物理的な信号をデコードするシステム及び方法を開示する。試験測定システム内において、ドメイン固有宣言型言語（domainspecific declarative language）は、宣言型言語の定義を用いて、シリアル、ネットワーク、又は通信プロトコルの特性をテキストで特定できる。宣言型言語で書かれたプロトコル宣言（protocol declaration）を実行する場合、プロセッサは、テキストで規定されたビットストリーム、イベント及びフィールドの定義に基づいて、プロトコル宣言を構文木に分解（parse）する。構文木自身は、サンプルされたデータの物理的な入力信号を、トランスポート、セッション又はアプリケーション・レイヤのような、より高いレベルのレイヤで使用するプロトコル固有の出力ビットストリームに変換するステート・マシーンとして機能できる。構文木におけるノードは、構文木を複数回繰り返すことができるように、再利用可能なステート・マシーン・コンポーネントとするか、再利用可能なステート・マシーン・コンポーネントとして機能しても良い。

エラーが生じがちで多くのデバッグを必要とするハイレベルの命令型（imperative）プログラミング言語で記述される完全なプロトコル・デコーダ・プログラムを必要とする従来のシステムと異なり、本開示の宣言型言語は、多数の異なるプロトコル間の基本的な構造的共通性を用いた単純化された要素を使用して、プロトコル宣言の定義及び評価を可能にする。このとき、従来のシステムがコード・クラッシュ及びメモリの問題を抱えていたとしても、本願で開示される最小宣言型言語セットによれば、プロトコル宣言の著者がメモリ又はメモリ・アロケーション・コールへ直接アクセスできないので、安全性と効率性の両方を備えた任意の物理レイヤのビットストリーム評価が可能である。このように、宣言型言語上のこれら制約のために、プロトコル宣言の著者が非安全なカスタム・ビットストリームを書いてしまうのを防止できる。

文字で指定されたプロトコル宣言（これは、ビットストリーム、イベント及びフィールド定義を含んでも良い）に基づいて、パーサが、デコーダ又はプロトコル固有のデコード・マシーン中に、構文木のステート・マシーン・コンポーネントをアセンブルする。言語インタープリタ（interpreter）と同様に、デコーダは、以下で詳細に説明するように、物理的な信号中に認識されたエッジをエッジ・データ・セットに集めて、未加工のビットストリームに変換することも含めて、構文木の各ノードで入力データの値を求めることによって実行する。構文木の実行は、適切な入力プロトコル伝送を記述するフィールドを有するフレーム化パケットのコレクションも出力できる。よって、シンプルな定義のセットを用いて、宣言型言語は、非常に柔軟で、多種多様なシリアル・プロトコルをデコードするのに利用できる。

宣言型言語は、プロトコル宣言を文字で指定するのに、例えば、以下の要素のいずれか又は全てを利用しても良く、これらは、以下で更に詳細に説明される：
（１）ビットストリーム定義
（２）イベント定義
（３）複雑なイベント定義
（４）イベント時間組み入れ／除外トークン
（５）条件に応じて調査の節（scoped if clauses）
（６）任意ビット・スタッフィング・ルール定義
（７）パケット定義の任意セクション内の調査領域
（８）フィールド・マッチング・ルール
（９）フィールド量化ルール
（１０）フィールド入れ子処理及びグルーピング処理
（１１）フィールド・プロパティ
（１２）フィールド・アクション定義
（１３）任意ＣＲＣ多項式定義
（１４）エラー及びＣＲＣフィールド・シーケンス定義

例示的な実施形態は、上記の例示的な要素、他の潜在的な要素及び結果として生じる構文木を用いて、宣言型言語のいくつかのユニークなプロパティを組み合わせ、任意のシリアル、ネットワーク又は通信プロトコルをデコードするのに利用可能な、ある程度の一般化を提供する。宣言型言語でコード化された定義は、通信ハードウェアが、組み込まれた特定のプロトコルに関係なく、物理的な信号及びそのエンコードされたデータを変換又はデコードするのを可能とし、このプロトコルとしては、データ・リンク・プロトコル（例えば、イーサネット、ポイント・トゥ・・ポイント（ＰＰＰ）、ハイレベル・データ・リンク・コントロール（ＨＤＬＣ）、アドバンスト・データ・コミュニケーション・コントロール・プロシージャ（ＡＤＣＣＰ））はもちろん、標準の又はカスタマイズされたライン・コード（伝送路符号）エンコーディング（例えば、ＮＲＺ、マンチェスタ）を含めることができる。

上述のように、プロトコル宣言は、ビットストリーム定義、イベント定義及びフィールド定義を含んでいても良い。ビットストリーム定義は、アナログ又は物理的な入力信号を、１及び０からなるバイナリ・ビットストリームにどのようにして変換するかを定義する。 イベント定義は、パケット・フレームの範囲をどのようにして検出又は生成するかを定義する。最後に、フィールド定義は、例えば、ヘッダ、フッタ、プロパティ、特性（characteristics）、アクション、フラグ付加処理、エラー対処処理などを含めて、ビットストリームの値を、どのようにしてパケットにマッピング又はマッチングさせるかを定義する。

具体的には、本開示の宣言型言語は、限定的な調査、ドメイン固有の文法を利用して、アナログの物理的な信号のビットストリーム・シーケンスへの変換を定義できる。アナログ信号は、例えば、試験プローブによって取り込んでも良い。この変換されたビットストリーム・シーケンスは、次いで、追加的なプロトコルの構文解析（parsing）に利用されても良い。このように、プロトコル宣言の著者は、プログラマである必要はなく、代わりに、比較的少ない言語要素のセットを学ぶだけで良い。物理的な入力信号を変換するための新しいビットストリーム定義を、その基礎となるランタイム・エンジンを変更することなく生成でき、これは、従来のシステムでは必要となるデバイス又は装置のファームウェアの変更を必要とせずに、これらのビットストリーム定義及び機能の展開を可能にする。

宣言型言語は、一般的な式の値を求める処理、変数宣言及び代入をサポートし、よって、入力についての任意の数学的及びブール演算が可能となる。更に、式の値を求める処理では、例えば、ブール、整数、浮動小数点及び現在エッジ値のようなデータ形式を許容する。

図１は、プロセッサ１４と、宣言型言語定義を格納するメモリ１６を含む例示的な試験測定システム１０を示す。試験測定システム１０には、物理的な媒体入力ライン２０を通して物理的な信号を受ける入力端子１８がある。この物理的な信号は、例えば、電圧、無線周波数又は赤外線光のような任意の既知の物理媒体を用いて伝送されても良い。試験測定システム１０には、システム１０と一体（図示のように）でも良いし、又はシステム１０の外部でも良いユーザ・インタフェース２２があっても良い。プロセッサ１４内か又はプロセッサ１４に結合されたパーサ（parser：構文解析器）４０は、プロトコル宣言の著者によってコード化され、メモリ１６に記憶された宣言型言語定義を使用して、構文木をコンパイルする。当業者には理解されるように、パーサ４０は、コンパイラやレクサ（Lexer：字句解析器）を含んでも良いし、これに代えて、パーサの代わりにコンパイラやレクサであっても良い。更に、プロセッサ１４は、入力端子１８においてシステム１０に入力された物理的な入力信号に対して構文木を実行する。構文木の実行は、プロトコル宣言の定義を利用して、入力端子１８におけるデータをビットストリームに変換し、これは、試験測定システム１０において更に処理されても良いし、出力ライン２４を通して出力されても良い。

図２は、宣言型言語で書かれた任意のビットストリーム定義１０２、イベント定義２０２及びフィールド定義３０２に基づいて、プロセッサ１４がパーサ４０を使ってどのようにメモリ１６に格納されたプロトコル宣言３０を実行して、構文木６０をコンパイル又は構築するかを示す。プロセッサ１４（図１）は、構文木６０を利用して、物理的な入力信号５０の値を求めて、ビットストリーム７０を出力する。

図３は、プロセッサ１４が宣言型言語で書かれたプロトコル宣言をどのように利用して、物理的な入力信号５０をデコードできるかを示す。この処理には、３つの主要な要素があり、これらは、構文木６０による次のデコード処理のステージに対応している：（１）プリアンブル・ステージ１００、ここでは、プリアンブルが物理的な入力信号５０の個数を定義し、これらをプロトコル宣言３０（図２）中のビットストリーム定義１０２を用いて、どのように未加工（raw：ロー、生）のビットストリーム７０へ変換するかを定義する；（２）イベント探索ステージ２００、ここでは、プロトコル宣言３０中のイベント定義２０２を用いて、フレーム化ビットストリーム・データ８０を出力するために、どのようにしてパケット・フレームの最初と最後を見つけるかを複数のルールで定義する；（３）フィールド・マッピング・ステージ３００、ここでは、プロトコル宣言３０中のフィールド定義３０２を用いて、パケット９０を生成するためのフィールド構造が特定のパケット形式内で定義される。

図２〜３を参照すると、プリアンブル・ステージ１００では、プロセッサ１４やパーサ４０は、構文木６０をコンパイルし、プロトコル宣言３０内のビットストリーム定義１０２を用いて、物理的な入力信号５０を未加工（生）のビットストリーム７０へ変換する。ビットストリーム定義１０２は、アナログ信号を、０と１からなるバイナリ・ビット・シーケンスに変換する標準的な物理レイヤの手法を特定しても良い。実施形態によっては、ビットストリーム定義１０２が、カスタム又はドメイン固有宣言型言語を用いて書かれていても良く、これは、転送されるデータにセキュリティを付加できる。しかし、別の実施形態では、ビットストリーム定義１０２が、標準的なライン・コード・エンコーディング・プロトコルを用いて書かれても良く、これらは、ライン・コード・エンコーディング・ライブラリに格納されていても良い。標準的なライン・コード・エンコーディング・プロトコルは、例えば、Ｃ言語のような標準的なチューリング完全プログラミング言語で書かれていても良い。

プロセッサ１４がプリアンブル・ステージ１００中に構文木６０を実行するときに、物理的な入力信号５０を未加工のビットストリーム７０へ変換することによって、物理的な入力信号５０をパケットのデコード処理に使えるようにする。プロセッサ１４は、プロトコル宣言３０のビットストリーム定義１０２に基づいて、構文木６０のノードを用いて、物理的な入力信号５０を、未加工のビットストリームを表すもの又は値に変換する。プロセッサ１４は、このビットストリーム変換を、プロトコル宣言３０内の予め定義したビットストリーム定義１０２を直接コールすることによって実行できる。

プリアンブル・ステージ１００の間、プロセッサ１４は、また、実施形態によっては、物理的な入力データについて付加的な計算を実行し、その後の論理ベースの判断に関する任意の設定の状態をチェックしても良い。プリアンブル・ステージ１００では、その後のステージのイベント検出及びフィールド・マッピング工程において使用される中間的な計算として、標準的な表現の評価及び変数割り当てがサポートされる。

イベント探索ステージ２００では、構文木６０がプロトコル宣言３０中のイベント定義２０２を利用して、ビットストリーム７０内のパケット・フレームの最初と最後のビットを見つけ、フレーム化ビットストリーム・データ８０を出力する。

フィールド・マッピング・ステージ３００では、構文木６０がプロトコル宣言３０中のフィールド定義３０２を利用して、フレーム化ビットストリーム・データ８０の各フレーム内の種々のフィールドの夫々を定め、パケット・ビットストリーム・データ９０を出力する。

図４は、更に、図３のプリアンブル・ステージの間に、物理的な入力信号４５０を異なるビットストリーム４７０ａ〜ｃへ変換するのに、プロトコル宣言３０内の種々のビットストリーム定義１０２をどのように利用できるかを時間プロット上で示す。図４の時間プロットの領域１０００中の特定の単一の物理的な入力信号４５０を用いて、プロセッサ１４は、領域１１００のビットストリーム定義を利用して、ノン・リターン・トゥ・ゼロ（ＮＲＺ）のライン・コード・エンコーディングに基づいて、物理的な入力信号４５０をビットストリーム４７０ａへ変換する。プロトコル宣言３０内において、領域１１００のビットストリーム定義は、次のように書くことができる：
bitstream A = nrz(data);
ここで「Ａ」は、ビットストリーム変換関数の結果を含む変数を表し、「nrz()」は、メモリに格納された所定の関数であり、「data」は、物理的な入力信号４５０のサンプルされたデータを表す変数である。図４に示すように、領域１０００の物理的な入力信号４５０は、領域１１００のビットストリーム４７０ａに重ねられ、その複数のエッジは、規則的な時間インターバルと合致していることが示され、時間インターバルにおいて、物理的な入力信号４５０は、領域１１００のビットストリーム定義の下で、その値に基づいて判断される。

同様に、領域１２００において、プロセッサ１４は、領域１０００の同じ物理的な入力信号４５０から、異なるビットストリーム４７０ｂを出力するのに、領域１２００のビットストリーム定義に基づくが、これは、次のように書くことができる：
bitstream A = NRZM(data);
ここで「Ａ」は、再度、ノン・リターン・トゥ・ゼロ・マーク・エンコーディングをデコードするための所定の関数に基づいて算出されたビット値のシーケンスを表し、NRZM()は、上述のように、ライン・コード・エンコーディング・ライブラリの予め定義され、格納された部分であっても良く、また、どのようにこの関数が所与の「data」、つまり、物理的な入力信号４５０について解くかであっても良い。図４に示すように、領域１０００の物理的な入力信号４５０が領域１２００のビットストリーム４７０ｂに重ねられ、その複数のエッジは、規則的な時間インターバルの中央にあることが示され、時間インターバルの間に、領域１２００のビットストリーム定義の下、物理的な入力信号４５０が、ロー（Low：低）からハイ（High：高）又はハイ（High：高）からロー（Low：低）へと遷移したかに基づいて評価される。

領域１１００と１２００のビットストリーム定義は、ビットストーム定義１０２が、標準的なライン・コード・エンコーディング・プロトコルに基づくものであり、これは、ライン・コード・エンコーディング・ライブラリで参照できると共に、格納できるものであり、また、異なるビットストリーム定義１０２は、異なるビットストリーム４７０ａ〜ｃを生じることを示す。これに代えて、ビットストリーム定義１０２が、特定のドメイン用にカスタマイズされても良く、これは、転送されたデータのセキュリティに追加することもできる。

カスタム・ビットストリーム定義１０２は、宣言型言語構文のサブセットを用いて定義できる。このサブセットだけを用いて、物理的な入力信号５０のビットストリーム７０への（即ち、物理レイヤのデータ・リンク・レイヤへの）解釈に関するルールを定義できる。カスタム・ビットストリーム定義１０２は、構文木６０にコンパイルしても良い。次いで、プロセッサ１４は、物理的な入力信号５０の構文木６０を実行して、ビットストリーム出力７０を生成する。カスタム・ビットストリーム関数について使用された文法のサブセットは、変数宣言、変数インクリメント／ディクリメント演算子、代入ステートメント（assignment statement）、静的マップ定義、条件に応じて調べる節（scoped if clause）及びイールド・ステートメント（yield statement）を含んでいても良い。

領域１３００のビットストリーム定義は、プロセッサ１４に物理的な入力信号４５０をビットストリーム４７０ｃとして評価させるもので、宣言型言語を用いて書かれた、こうしたカスタマイズしたビットストリーム定義の例である。領域１３００のカスタム・ビットストリーム定義は、プロトコル宣言３０自身内で定義しても良いし、又は、単純に、プロトコル宣言３０内で参照されて、どこか別の場所に格納されても良い。例えば、もしプロトコル宣言３０内で参照されるなら、領域１３００のビットストリーム定義は、領域１１００及び１２００のビットストリーム定義と同様に、所定関数を参照する次の式として書くこともできる：
ビットストリームＡ＝ｇｅｔｂｉｔｓ（ｄａｔａ）
ここで「Ａ」は、変換されたビットストリーム・データを表す変数であり、「ｇｅｔｂｉｔｓ（）」は、任意のユーザ定義関数であり、「ｄａｔａ」は、領域１０００の物理的な入力信号４５０である。別の例として、領域１３００のユーザ定義カスタム・ビットストリーム定義は、プロトコル宣言３０内に直接定義することもでき、次のようにＳＥＮＴバス・プロトコルに基づいても良い：

bitstream getbits(pin data) {
bool isFall = false;
double pw = 0.0; double start = 0.0; double end = 0.0; double zeroWidth = 0.0;
double t1 = 0.0; double t2 = 0.0; double t3 = 0.0; double dataWidth = 0.0;
double lowerWidthBound = 0.0; double upperWidthBound = 0.0;
double UT = env.getvalue(“ut”, 0.000003);
if(UT<0.000003) { UT = 0.000003; }
if(UT>0.000010) { UT = 0.000010; }
int bit0 = 0; int bit1 = 0; int bit2 = 0; int bit3 = 0; int nibble = 0;
isFall = data == 0;
start = pintime(data);
end = pintime(data[2]);
pw = end ? start;
zeroWidth = 12.0 * UT;
lowerWidthBound = 11.0 * UT;
upperWidthBound = 28.0 * UT;
dataWidth = pw ? zeroWidth;
nibble = (int) ((dataWidth / UT) + 0.5);
t1 = start + UT;
t2 = t1 + UT;
t3 = t2 + UT;
bit0 = (nibble >> 3) & 0x1;
bit1 = (nibble >> 2) & 0x1;
bit2 = (nibble >> 1) & 0x1;
bit3 = nibble & 0x1;
if (isFall && pw > lowerWidthBound && pw < upperWidthBound) {
yield([start, bit0], [t1, bit1], [t2, bit2], [t3,bit3]);
}
yield();
}

ここで、物理的な入力信号４５０のエッジのクロック時間は、複数の時点（即ち、「pw」、「dataWidth」）間の差分の可変幅に基づいてわかると共に、値が求められる。図４に示すように、エッジ・データのセットには、物理的な入力信号４５０の０値を囲むエッジを含み（「isFall = data == 0」を用いて見つかる）、これは、ＳＥＮＴプロトコルに従って標準的な幅で離れている（即ち、「６ＵＴ」）。標準的な「ゼロの幅（zeroWidth）」（即ち、図４では０.０４ｍｓ）が、下向きの立ち下がりエッジ間の時間差（即ち、「pw」、これの最初のものは、図４では０.０８ｍｓとして示される）から引き算されて、「データ幅（dataWidth）」値を生じる。この「データ幅（dataWidth）」値（例えば、０.０８ｍｓ−０.０４ｍｓ＝０.０４ｍｓ）は、次いで、「ＵＴ」の観点からＵＴを除数として数値が求められて（例えば、０.０４ｍｓ／０.００３３３…ｍｓ＝１２）、整数の「ニブル」値（例えば、１２のバイナリ形式は、１１００）がもたらされる。よって、図４に示すように、ビットストリーム４７０ｃの最初の４ビット値（つまり、「ニブル」）は、領域１０００の物理的な入力信号４５０の最初の２つの下向きの立ち下がりエッジ間の時間の長さに基づいて、「１１００」である。

言い換えると、ランタイム・エンジンは、領域１３００のカスタム・ビットストリーム定義を、データ・フロー・シーケンス中のある状態を有するイテレータ（iterator：反復子）として扱う。最初に、図４に示すように、しきい値／ヒステレシスを、領域１０００の物理的な入力信号４５０に対して適用して、エッジのセットを抽出して生成する。このエッジ・データ・セット中のエッジ定義には、立ち上がり／立ち下がりの指示（例えば、「isFall=data==0」）及びタイムスタンプが含まれても良い。エッジ・データ・セットは、次いで、領域１３００のカスタム・ビットストリーム定義に基づく抽象構文木６０のノードを通して、一度に１エッジで、繰り返し適用されても良い。領域１３００のこのカスタム・ビットストリーム定義は、静的な（static）変数宣言（例えば、「double start = 0.0」、「start = pintime(data)」）を利用して状態を維持し、また、物理的な入力信号４５０を通して、認識されたエッジの値を求めることによって、繰り返し適用されながら、初期宣言値にリセットするのではなく、各繰り返しで値を更新する。変数宣言は、Ｃプログラミング言語における静的（static）キーワードと同様のやり方で、自動的に静的（static）と定義されても良く、このとき、変数宣言は、最初のコールで設定された値のみを持つことになる。領域１３００のカスタム・ビットストリーム定義に対するプロセッサ１４による後続の繰り返しコールの夫々は、変数宣言値にリセットするのではなく、変数を以前の値に維持するという結果を生じる。プロセッサ１４は、ビットストリーム定義１０２を用いて、代入（assignments）、変数（variables）及び式（expressions）の値を求め、続いて、エッジ・データ・セット中の所与のイテレータの位置に関するゼロ以上のビットを返答する。具体的には、イールド・ステートメント（即ち、「yield()」）は、プロトコル宣言の著者が、あるエッジ繰り返しに関するゼロ以上のビットを返答するのを可能にできる。タイムスタンプと論理ビット値（例えば、「start, bit0」、「t1, bit1」）を有するペアを含むタプル（tuple）を用いて、１以上のビットが返答されることもある。ランタイムの実行中、構文木６０のイールド・ノード（yield node）は、イールド・ステートメントに基づいて、論理ビット値をパース・コンテキスト・オブジェクト（parse context object）へと押し出す。次いで、関数ノードは、各入力エッジについて、領域１３００のカスタム・ビットストリーム定義のステートメントを通して繰り返し適用され、イールド・ノードが返答すると、パース・コンテキスト・オブジェクトからビット値を取り出す。

ビットストリームの値を求める処理は、領域１０００の物理的な入力信号４５０内における現在の状態の条件に基づいて、分岐しても良い。プロトコル宣言３０内で使用される宣言型言語は、この分岐処理をサポートするために、scoped if-else 節を含んでいても良い。例えば、領域１３００のカスタム・ビットストリーム定義は、次の例示的なｉｆ節（条件節）を含んでいても良い：

if (isFall && pw > lowerWidthBound && pw < upperWidthBound) {
yield([start, bit0], [t1, bit1], [t2, bit2], [t3,bit3]);
}

ここで、ブール型の「isFall」と、「pw」の比較は、条件分岐を表し、これは、もし満たせば、内部コードのイールド・ステートメントへのアクセスが許される。

加えて、宣言型言語は、領域１３００のカスタム・ビットストリーム定義から生成された構文木６０のノードを通した各繰り返しに関して、現在の位置におけるタイムスタンプ及びエッジ値を抽出する構文を提供する。この情報は、所与のエッジ入力に関するビット値を計算するのに利用できる。例えば、領域１３００のカスタム・ビットストリーム定義は、次の代入（assignments）があっても良い：

double UT = env.getvalue(“ut”, 0.000003);
isFall = data == 0;
start = pintime(data);
end = pintime(data[2]);
pw = end ? start;
dataWidth = pw ? zeroWidth;
nibble = (int) ((dataWidth / UT) + 0.5);
bit0 = (nibble >> 3) & 0x1;
bit1 = (nibble >> 2) & 0x1;
bit2 = (nibble >> 1) & 0x1;
bit3 = nibble & 0x1;

ここで、タイムスタンプ及びエッジ値は、「ｕｔ」の環境変数及び「データ（data）」信号の値に基づいて抽出される。図４に示すように、各立ち下がりエッジ間（即ち、エッジ・データ・セット中に見られる第１及び第３エッジ間）の距離は、次いで、整数の変数「ニブル」を計算するのに利用でき、これのバイナリ形式は、４ビット値を生じるのに利用される。このように、エッジ値及びタイムスタンプ・データ（例えば、「start」、「t1」、「bit0」）が抽出されて、データ・ストリーム中の現在の繰り返し位置と関係づけられる。

更に、宣言型言語は、現在の繰り返し位置からの任意のオフセット位置におけるタイムスタンプ及びエッジ値を抽出する付加的な構文も提供できる。これは、領域１０００の物理的な入力信号４５０内のエッジ位置間のタイミング差の値を求めるのを可能にする。ランタイム環境は、任意のオフセットのあるアクセスが、入力エッジ・セットの実際の範囲に確実に限定されるように制約を強いる。領域１３００のカスタム・ビットストリーム定義は、後述のように、上限及び下限内に制限され、この定義は、この定義に該当しない物理的な信号のデータ・ストリームの領域に関して、コード中にエラーを生じることなく、ゼロ・ビット値を返答する又は生じることになる。よって、エッジ・イテレータが設定範囲外のデータ値を参照することは許されないので、プロトコル宣言の著者には、範囲の無事（safety）が約束されるという利点がある。例えば、領域１３００のカスタム・ビットストリーム定義が、次の代入とｉｆ節の条件を含んでも良い。

lowerWidthBound = 11.0 * UT;
upperWidthBound = 28.0 * UT;
if (isFall && pw > lowerWidthBound && pw < upperWidthBound) {

ここで、「lowerWidthBound」より小さいか、又は、「upperWidthBound」より大きいエッジ間の任意のタイミング差（即ち、「pw」）は、そのオフセットがエッジ・データ・セットの範囲を越えるであろうことから、無視される。

このように、図４は、領域１０００の同じ物理的な入力信号４５０を、結果として得られる異なるビットストリーム４７０ａ〜ｃへデコードするための、領域１１００〜１３００の変化するビットストリーム定義を書くのに、宣言型言語がどのように利用できるかを示している。このように、ライブラリに格納されたプロトコル宣言の明確な定義や予め定めた関数のコールに基づいて、物理的な入力信号をデコードするように、試験測定システムを容易にプログラムすることもできる。こうして、物理的な入力信号５０は、その個別のネットワーク・プロトコルに関係なく、同じ構文木６０を用いて、ビットストリーム７０に適切に変換でき、構文木６０は、その後のイベント探索及びフィールド・マッピング・ステージ２００及び３００において使用されるか、又は、データ・リンク・レイヤ、ネットワーク・レイヤ又はトランスポート・レイヤのようなレイヤにおいて使用されることになる。

次に、イベント探索ステージ２００のデコード処理の間、プロセッサ１４は、構図木６０のノードを用いて、入力データ（プリアンブル・ステージ１００のビットストリーム出力７０又はロー（未加工）の物理的な入力信号５０のいずれかとしても良い）をスキャンし、プロトコル宣言３０内のイベント定義に基づいて、所与のパケット形式又はプロトコルについて開始及び終了イベントを見つける。具体的には、プロトコル定義３０のイベント定義２０２は、値、パターン、限定子（qualifiers）及び持続時間の仕様を利用して、アナログ、エッジ又はビット状態の値を求めることによって、パケットのフレーミング範囲の検出を特定しても良い。これらの開始及び終了イベントは、物理的な入力信号５０やビットストリーム７０内のパケット・フレームをゲートするか又は示す時間マーカである。見つかったフレーミング時間マーカは、フィールド・マッピング・ステージ３００に渡される。

図５は、ＬＩＮプロトコルに基づいて書かれたプロトコル宣言３０に従った構文木６０の実行のデコード・ステージを示す。プリアンブル・ステージ１００の間、プロセッサ１４は、部分的には、以下のように書かれたプロトコル宣言３０に従って、物理的な入力信号５０に対して構文木６０を実行しても良い：

{Settings: polarity<“normal”>(“normal”, “invert”) }

decoder LIN(pin data) {
int dominant = 0; int recessive = 1;
bool invert = env.checkValue(“polarity”, “invert”);
bitstream A = invert ? ~nrz(data) : nrz(data);

ここで「Settings」は、ユーザ・インタフェース上で可能な設定を示し、これは、プロトコルがユーザの選択をランタイム・エンジンに返すのに必要とされると共に、「nrz()」関数を利用し、ビートストリーム５７０が結果として生じる「Ａ」のビットストリーム定義に必要とされることがある。「polarity（極性）」の設定では、「normal（正常）」が選択され、「invert（反転）」が選択されなかったので、作成された「invert」と呼ばれるブール変数は、偽となり、「~」のビット単位補数演算子（bitwise complement operator）を用いてビットストリーム「Ａ」は反転されない。

プリアンブル・ステージ１００の後、ビットストリーム５７０は、次のステージ２００のイベント探索処理に渡され、このとき、プロトコル宣言３０内のイベント定義２０２に基づいて、プロセッサ１４によって、開始及び終了フレーミング時間マーカの値が求められる。イベント５８２に関するイベント定義は、プロトコル宣言３０内に次のように定義することもできる：
event SynchBreak = (A:10 == 0000000001b);
ここで、プロセッサ１４は、９個の０と、これに１が続くシーケンスを形成する、ビットストリーム「Ａ」５７０内の１０個のビットを探す。イベント５８２に関するイベント定義には、マッチング・ルール（「A:10==0000000001b」)の例を含み、これは、値、パターン、マスク・マッチング及び正規表現の定義を有する、プロトコル宣言３０の宣言型言語の一部として利用できる。加えて、宣言型言語で書かれた、プロトコル宣言３０内のイベント時間組み入れ／除外トークン（token）は、パケット・フィールドの値を求める間に、例えば、次のように、プロセッサ１４がパケット・イベントの開始の終了時間マーカと一緒にデータ・ビットを含めるべきかどうかを指定する柔軟性をユーザに与える：
packet DataPacket = Start
packet DataPacket = ( Start ]
ここで「= Start」の形式は、終了時間を含むことを意味し、「= ( Start ]」の形式は、終了時間を除外することを意味する。図５を参照すると、イベント５８２は、ビットストリーム「Ａ」５７０内のパケット・フレーム５８０の開始を合図している。イベント５８２を表すこれら１０個のビットに続いて、プロセッサ１４は、構図木６０に従ってフィールド・マッピング・ステージ３００に進み、プロトコル宣言３０内に定義されたフィールド定義３０２と一致するバイナリ・シーケンスを求めて、パケット・フレーム・データ５８０を調べる。

具体的には、フィールド・マッピング・ステージ３００において、プロセッサ１４は、パケット探索ステージ２００で求められたフレーム位置又はパケット・フレームにおいて、ビットストリームの値を、可能性のあるパケットにマッピングする。加えて、プロセッサ１４は、そのフレーム内の関連するフィールドを、特定のプロトコルに関してプロトコル宣言３０のフィールド定義３０２で定義されているようにマッピングする。プロセッサ１４は、ビットマップ・メモリ５８０の変換された入力データ・ビットに対して、的確に限定した対応するパターンのセットを比較することによって、このフィールド・マッピングを達成する。これらパターン・マッチングは、シンプルなビット・フィールドの比較や、正規表現を用いた複雑な比較でも良い。プロセッサ１４は、次いで、これら的確に限定した対応するフィールドを用いて、ビットストリーム５９０のゲートされた又はフレーム化した区間の値を求め、宣言されたパケット形式のどれが入力データの構造とマッチングするかを決定する。

フィールド定義３０２は、上述のイベント定義２０２と同じルール・マッチングの特性を含んでも良い。パケット構成及び表現の柔軟性を高めるために、フィールド定義３０２は、更にいくつかのパターン及び特性を用いて定義しても良い。図５のフィールド５９１及び５９２のフィールド定義は、次のようにプロトコル宣言３０内に定義することもできる。
field StartBit = { (A:1) == dominant };
field StopBit = { (A:1) == recessive };
ここで、８ビットのバイトの開始は、０のビット値を有する先行するビットにフラグが付き、このバイトの終了は、１のビット値を有する後続のビットにフラグが付けられる。

より良い論理的な表現のために、複数のフィールドを、新しい「仮想（バーチャル）」フィードへと任意に再合成しても良い。図５のフィールド５９３に関するフィールド定義は、次のようにプロトコル宣言３０内に定義することもできる：
field SynchFields = { StartBit, A.Synch:8.verify(__value, “Invalid synch field”, 0x55), StopBit };
ここで、フィールド５９３は、１０個のビットから構成され、１ビット・フィールド５９１で始まり、これにビット・シーケンス０１０１０１０１を有する８ビットの「synch（同期）」フィールドが続き、そして、１ビット・フィールド５９２で終わる。フィールド５９３に関するフィールド定義は、フィールド定義３０２が、既定のフィールド内に他のフィールをどのように入れ子にする（nest）かを示している。

図５のフィールド５９４に関するフィールド定義は、次のようにプロトコル宣言３０内に定義することもできる：
field InterFrameSpace = { { (A:1) == recessive } {0, 15} };
ここで、フィールド５９４は、関係演算子「==」の真の結果の繰り返しに基づいて、ゼロから５ビットの長さを持ち得る。フィールド・マッチング・ルールに加えて、そして、フィールド・マッチング・ルールに比べて、フィールド定義３０２は、固定又は任意長のフィールドの繰り返しを可能にするフィールド量化（quantifier）ルールを含んでも良い。フィールド５９４に関するフィールド定義には、フィールド量化子「{0, 15}」の例があり、ここで、「０」は、最小フィールド長、「１５」は、固定フィールド５９４についての最大フィールド長である。固定フィールド量化子（quantifier）は、（１）「{n}」、ここで、先行する要素は、正確にｎ回マッチングしなければならない。（２）「{n, m}」、ここで、先行する要素は、少なくともｎ回マッチングしなければならないが、ｍ回より多くてはいけない。（３）「?」、ここで、先行する要素は、１回マッチングするか、又はマッチングしない必要がある、という形式である。フィールドは、任意のビット幅や長さで定義されても良く、これは、（１）「＊」、ここで先行する要素は、ゼロ回以上マッチングしなければならない。（２）「＋」、ここで先行する要素は、１回以上マッチングしなければならない。（３）{n, }、ここで先行する要素は、少なくともｎ回マッチングしなければならない、という形式を利用しても良い。

図５のフィールド５９５に関するフィールド定義は、次のようにプロトコル宣言３０内に定義することもできる：

field IdFields = { InterFrameSpace, StartBit, A.ID0#EXCLUDE:1, A.ID1#EXCLUDE:1, A.ID2#EXCLUDE:1, A.ID3#EXCLUDE:1, A.ID4#EXCLUDE:1, A.ID5#EXCLUDE:1, A.P0#EXCLUDE:1.verify(__parity, even, ID0, ID1, ID2, ID4), A.P1#EXCLUDE:1.verify(__parity, odd, ID1, ID3, ID4, ID5), StopBit, Identifier {ID0, ID1, ID2, ID3, ID4, ID5, P0, P1} };

ここで、フィールド５９５は、０から１５ビットのフィールド５９４で始まり、これに１ビットのフィールド５９１、次いで、８ビットの「識別子（Identifier）」フィールドが続き、そして、１ビットのフィールド５９２で終わる。フィールド５９５についてのフィールド定義には、「識別子」フィールドの１ビット・フィールドの夫々に使用されるフィールド・プロパティ（特性、属性）の例を含み、ここで、「#EXCLUDE」トークンは、ランタイムの値を求める処理中において、結果の後処理を可能にする。更に、付加的な後処理工程のために、フィールド・マッピング中に、フィールドにタグ付けしたいか又は結びつけたい任意のプロパティに関して、「#」トークンの変形が可能である。加えて、フィールド５９５についてのフィールド定義内の「識別子」フィールドに関するフィールド定義は、フィールドの入れ子処理（nesting）の例である。フィールドの入れ子処理及びグルーピングによって、各レベルにおいて別々の量化ルールを有する入れ子構造が可能になる。最後に、上記フィールド定義中のフィールド「P0」及び「P1」は、データ検証を含み、ここで、「識別子」フィールド内の４つのフィールドは、「P0」及び「P1」フィールドの夫々に対し、偶数又は奇数パリティに関して比較及びチェックされる。

ドメイン固有宣言型言語によれば、プロトコル宣言３０が、上述の「#EXCLUDE」トークンのようなアクション及びプロパティ・パラメータを有するフィールド定義３０２を含むことが可能になる。プロセッサ１４は、構文木６０の実行中に、これらアクション及びプロパティ・パラメータの値を求める。アクション・パラメータは、パーサ４０が認識できる予め定めたトークンでも良い。アクション・パラメータは、プロセッサ１４が、ビットストリームの値を求める処理の特性を変更したり、成功したフィールド・マッチングに対して他の演算を実行するのに利用できる。フィールド定義３０２内のフィールド・アクション・パラメータは、任意のランタイム・ステート・マシーンが、例えば、次のように、フィールド・マッチング条件に基づいて、変化することを可能にする：

(A.DTS2:1) == HIGH <ENABLE_STROBE_SYNC>,

ここで「<ENABLE_STROBE_SYNC>」は、例示的なアクション・パラメータである。フィールド・アクション・パラメータに比較して、プロパティ・パラメータは、フィールドに対して任意のプロパティを設定するトークンであっても良い。プロパティ・パラメータ・トークンは、プロセッサ１４が、フィールドの結果の前処理及び後処理のために利用しても良い。フィールド・プロパティ・パラメータは、上述した「#EXCLUDE」トークンのような所与のフィールド定義に関する任意のランタイムの値を求める処理のルールを確立する。

図５のフィールド５９６に関するフィールド定義は、次のようにプロトコル宣言３０内に定義することもできる：
field DataFields = { InterFrameSpace, StartBit, A.Data:８, StopBit };
ここで、フィールド５９６は、ゼロから１５ビットのフィールド５９４で始まり、これに１ビットのフィールド５９１、次いで、８ビットの「データ（data）」フィールドが続き、そして、１ビットのフィールド５９２で終わる。

図５のフィールド５９７に関するフィールド定義は、次のようにプロトコル宣言３０内に定義することもできる：

field ClassicCheckSumFields = { InterFrameSpace, StartBit, A.Checksum:8.verify(__checksum, CARRYON, Data), StopBit };

ここで、フィールド５９７は、ゼロから１５ビットのフィールド５９４で始まり、これに１ビットのフィールド５９１、次いで、８ビットの「チェックサム（Checksum）」フィールドが続き、そして、１ビットのフィールド５９２で終わる。フィールド５９７に関するフィールド定義には、「__checksum」を用いて、フィールドが「データ」フィールドであるか否か、つまり、先の８ビットの「データ」フィールドの適切なチェックサムの総計であるか否かを評価する、データ検証の別の例を含む。

プロトコル宣言３０中のフィールド定義３０２は、ユーザ定義のエラー対処処理（error handling）やフラグ付加処理（flagging）を含んでも良い。このエラー対処処理によれば、プロトコル宣言の著者が、巡回冗長検査（cyclic redundancy check： CRC）の結果、チェックサム、パリティや値を検証することが可能になる。この検証工程は、プロトコルを捕捉して調査及びデバッグするのに、エンド・ユーザにエラー状態を示すことが可能になる。フィールド定義３０２内の任意のＣＲＣ多項式定義は、例えば、次のように、ＣＲＣエラー・チェックを可能にする：
__crc HeaderPoly = x^11 + x^9 + x^8 + x^7 + x^2 + 1, 0x01A, 0;
エラー及びＣＲＣフィールド・シーケンス定義は、ばらばらのパケット区間に対して、パリティ、チェックサム、ＣＲＣその他のデータ検証計算を可能する（例えば、「verify(__parity, even, ID0, ID1, ID2, ID4)」）。更に、デコードされたフィールドの結果に連結する、プロトコル宣言の著者によって書かれたエラー・メッセージを可能にする変数置換（variable substitution）を有するユーザ定義の文字列のような検証フィールド定義が可能である。ユーザ・インタフェースは、ランタイム・エンジンによって検出されたランタイム／デコード処理エラー・メッセージを表示しても良い。

図５のフィールド５９８に関するフィールド定義は、次のようにプロトコル宣言３０内に定義することもできる：
packet MASTER_REQUEST_FRAME = SynchBreak { LSB { SynchFields, IdFields, {ID0, ID1, ID2, ID3, ID4, ID5} == 0X3C, {DataFields} {8}, ClassicCheckSumFields } };

ここで、可変長パケット・フィールド５９８は、パケット開始イベント５８２（同時のデータを含む）で始まり、これにフィールド５９３、次いで、フィールド５９５が続き、これにフィールド５９６（ここで、フィールド・パターン５９６は、フィールド量化子「{8}」に従って８回生じる必要がある）が続き、そして、フィールド５９７で終わる。フィールド５９８に関するパケット・フィールド定義は、フィールド・パターンを繰り返すために、正規表現形式のリピート・フラグと共に、どのように複数のフィールドをグルーピングするかを示している。具体的には、フィールド５９８についてのパケット・フィールド定義に関して、フィールド５９５内の「識別子（Identifier）」フィールドは、ビット・シーケンス１１１１００で始まらなければならない。この要件は、フィールド・マッチング・ルール「{ID0, ID1, ID2, ID3, ID4, ID5} == 0X3C」で示されている。また、フィールド５９８に関するパケット・フィールド定義内には、パケット・フィールド５９８のある区画についての特定の値を求める処理（ここでは、「ＬＳＢ」）の例がある。パケット形式についてのフィールド定義３０２内の区画又は調べた区画によって、プロセッサ１４に対して、例えば、ビット・スタッフィングのルール、最下位ビット（ＬＳＢ）、最上位ビット（ＭＳＢ）、ビッグ・エディアン、リトル・エディアンのような値を求める処理で使用する形式を特定しても良い。

任意のビット・スタッフィング・ルールが、例えば、次のように、フィールド定義３０２内に含んでいても良い：

bitstuff stuffComplement = (0b, 5) | (1b, 5);
field RemoteFrameFields = {
stuffComplement {
{ RTR } == recessive,
A.CRC:15.verify(__crc, CAN_P, Identifier-DataLengthCode, SOF<-0) } };

ここで、ビット・スタッフィング定義「stuffComplement」は、周知のように、特定のフラグ、マーカその他のフィールドが、ビットストリーム中のデータやその他のフィールドに、誤って読み込まれるのを防止する。本開示の宣言型言語を用いると、プロトコル宣言の著者は、特定のアプリケーションに適した、カスタマイズされたドメイン固有のビット・スタッフィング・ルールを書くことができる。プロトコル宣言３０が、メモリ１６又は他の記憶媒体中のライブラリに格納された共通のビット・スタッフィング・ルールへのコールを含むようにしても良い。

加えて、ビットストリーム定義１０２について上述のように、フィールド定義３０２及びイベント定義２０２は、ブール式の値を求める処理に基づいて、フィールド定義に関する分岐ロジックを可能にする、条件に応じて調べる節（scoped if clauses）を含んでいても良い。

実施形態によっては、２つ以上の物理的な入力信号５０を受けるようにしても良い。例えば、データ信号と共に、クロック信号を受けるようにしても良い。図６は、Ｉ２Ｃプロトコルに基づくプロトコル宣言３０を有する２つの異なる物理的な入力信号６５０用いる、構文木６０の３つのデコード処理ステージを示す。プリアンブル・ステージ１００の間に、プロセッサ１４は、プロトコル宣言３０に従って２つの物理的な入力信号６５０に対して構文木６０を実行でき、これは、部分的には、次のように書いても良い：
decoder I2C(PIN clk, PIN data) {
bitstream A = clock(data) @ rise(clk);
ここで、「PIN clk」及び「PIN data」は、２つの異なる物理的な入力信号６５０を表し、ビットストリーム６７０は、クロック（「clk」）信号がロー（Low：低）からハイ（High：高）に行く毎のデータ（「data」）信号に基づいて、ビット値を求めることによって生成される。

イベント探索ステージ２００の間に、パケット・フレームの開始及び終了の時点又は位置が、プロトコル宣言３０中のイベント定義２０２ に基づいて見つけられる。図６のイベント６８２及び６８４に関するイベント定義２０２は、次のようにプロトコル宣言３０中に書くこともできる。
event S = fall(data) when clk == 1;
event P = rise(data) when clk == 1;
ここで、イベント６８２は、クロック信号がハイ（high）の間に、データ信号がハイ（high）からロー（Low）へ行く度に生じ、イベント６８４は、クロック信号がハイ（high）の間に、データ信号がローからハイへ行く度に生じる。イベント６８２及び６８４に関するイベント定義は、ビットストリーム６７０内でパケット・フレーム化の範囲を見つけるために、プリアンブル・ステージ１００から出力されたバイナリのビットストリームではなくて、未加工（raw）のアナログの物理的な入力信号を用いるイベント探索ステージ２００の例を示す。

イベント探索ステージ２００の間に、プロセッサ１４によって複雑なイベントの値も求めることができる。複雑なイベント定義は、任意の個数のもっと単純なイベントの値を求める処理を組み合わせることを可能にし、これは、オプションで持続時間の仕様を有し、論理的な「ＯＲ」の組み合わせや複数のイベントのシーケンスを用いて、値を求めることができる。例えば、複雑なイベントに関する複雑なイベント定義は、プロトコル宣言３０内に宣言型言語で次のように書いても良い：
cevent SR = peek S;
cevent SRP = (P | SR);
ここで、複雑なイベント「SR」は、「peek（データを覗く）」動作に従って、イベント「S」が見つけられてスタックに加えられるといつでも生じ、複雑なイベント「SRP」は、構文木６０が、（１）上記のイベント６８４に関するイベント定義に従って定義されるイベント「P」、又は（２）複雑なイベント「SR」のいずれかに出会ったときにはいつでも生じる。

図６のフィールド６９２、６９４、６９６及び６９７は、全て、次のように、プロトコル宣言３０で書かれるフィールド６９８に関するパケット・フィールド定義中に定義されても良い。
int WRITE = 0; int READ = 1;
packet Read7 = S {
A.Address:7, (A.RW:1)==READ, A.Ack:1, (A.Data:8, A.Ack:1)+ } SRP;
ここで、パケット・フィールド６９８は、ゼロ・ビットのイベント６８２で始まり、これに７ビットの「アドレス（Address）」フィールド６９２及び１ビットの「RW」フィールド６９４（ここで、ビット値は１）、次いで、８ビットの「Data（データ）」フィールド６９７の少なくとも１つのグループ化したものに先行して、１ビットの「Ack」フィールド６９６、そして、複雑なイベント「SRP」で終わる。

図７は、本開示のいくつかの実施形態による、一般化した構文木（構文木）の実行の例示的な処理及びデータ・フローのブロック図を示す。構文木は、プロトコル固有のステート・マシーンを自動生成するのに利用できる。このプロトコル固有のステート・マシーンは、プロセッサが、ランタイムで入力データの値を求める処理を実行するのに利用できる。パーサ４０は、メモリ１６からプロトコル宣言７３０を読み出し、パーサ４０又はプロセッサ１４内のコンパイラ７０６は、構文木６０をコンパイルする。

物理的な入力信号７５０は、一般に周知の物理的なライン・コード（伝送路符号）のエンコーディング又はプロトコル宣言３０に基づくカスタム・ビットストリーム定義を用いてデコードされる。図７に示すように、上述のようなカスタム・ビットストリーム定義を書くことではなくて、又は、これに加えて、標準的なデコーダ７０２が、一般に周知の物理ライン・コードのコーディング又はエンコーディング・スキームを利用して、物理的な入力信号７５０を未加工（raw：ロー）のビットストリーム７７０へと変換しても良い。一般に周知の物理ライン・コードのコーディング又はエンコーディング・スキームとしては、例えば、マンチェスタ（Manchester）、リターン・トゥ・ゼロ、ノン・リターン・トゥ・ゼロ（ＮＲＺ）、ノン・リターン・トゥ・ゼロ・マーク（ＮＲＺ−Ｍ）、データ・ストローブ（Ｄ／Ｓ）、２ｂ／１０ｂ、８ｂ／１０ｂ、８ｂ／９ｂ、６４ｂ／６６ｂ、６４ｂ／６７ｂ、１２８ｂ／１３０ｂ及びデスクランブル（descramble：スクランブルを解く）がある。これら一般に周知の物理ライン・コードのコーディング又はエンコーディング・スキームは、ライン・コード・エンコーディング・ライブラリ７７２に含まれて、デコーダのサポートに利用されても良い。ビットストリーム定義は、静的なＣ＋＋のコルーチン（co-routine）として書かれても良く、これは、構文木を実行するデコーダのランタイム・エンジンによって直接読み出される。この手法の下、ランタイム、文法（grammar）及びｌｅｘトークンが、新しい物理的レイヤ・ビットストリーム定義と出会う度に更新される。この更新処理は、プロトコル固有の情報フローへのビットストリーム・シーケンスの分析及びマッピングに重点を置く、言語ベースのプロトコル手法のどれにでも利用できる。

プロセッサ１４は、続いて、構文木７６０を実行し、フレーム又はイベント定義２０２を用いて、標準的なデコーダ７０２からの未加工のビットストリーム７７０をビットストリーム・フレーミング（フレーム化）データ７８０へと変換する。構文木７６０は、次いで、フィールド定義３０２を出力されたパケット化ビットストリーム・データ７９０に対してマッチングさせる。また、先に詳細を説明したＣＲＣチェック７１２を実行しても良い。

フィールド・デバイス・アクセス（ＦＤＡ）及びデバイス記述言語（device description language：DDL）ライブラリ７８２を用いて、ビットストリーム７７０の値を求めて（evaluate：評価して）、プロトコル宣言３０によるトークン交換を用いて、元々の入力データを出力メディア・ファイルへと変換しても良い。デコードされたビットストリームのフレーム及びパケットが収集され（７１４）、パケットからペイロードが抽出されて（７１６）、メディア・ファイル７１８が求められる。パケット・コレクション（collection）７１４は、データ・ストア７２０にも保存されても良い。

説明のために、種々の例示的な定義を先に提示したが、本開示の実施形態は、こうした定義に限定されず、宣言型言語を用いて、定義の多様な配列がプロトコル宣言の著者によって書かれても良い。

本願発明の態様は、様々な変更及び代替形態が可能である。特定の態様は、図面に例として示されており、本願で以下に詳細に説明する。しかしながら、本願に開示された実施例は、説明を明確にする目的で提示されており、明示的に限定されない限り、開示される一般的概念の範囲を本願に記載の具体例に限定することを意図していない。このように、本開示は、添付の図面及び特許請求の範囲に照らして、記載された態様のすべての変更、均等物及び代替物をカバーすることを意図している。

物理的レイヤのアナログのシグナリングは、カスタム・ハードウェア・チップセット、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）その他の汎用言語アルゴリズムによって、ビットストリームに変換できる。

明細書における実施形態、態様、実施例などへの言及は、記載された項目が特定の特徴、構造又は特性を含み得ることを示す。しかしながら、開示される各態様は、そうした特定の特徴、構造又は特性を含んでいても良いし、必ずしも含んでいなくても良い。更に、このような言い回しは、特に明記しない限り、必ずしも同じ態様を指しているとは限らない。更に、特定の態様に関連して特定の特徴、構造又は特性が記載されている場合、そのような特徴、構造又は特性は、そのような特徴が他の開示された態様と明示的に関連して記載されているか否かに関わらず、そうした他の開示された態様と関連して使用しても良い。

本開示の態様は、特別に作成されたハードウェア、ファームウェア、デジタル・シグナル・プロセッサ又は試験測定に適合化されたコンピューティング装置のような、プログラムされた命令に従って動作するプロセッサを含む特別にプログラムされたコンピュータ上で動作できる。試験測定に適合化されたコンピューティング装置は、試験測定システムを網羅しても良い。入力データは、物理チャンネル入力部から直接供給されても良い。これに加えて又はこれに代えて、入力データは、以前にサンプリングされた又は合成されたライン・コード化された物理的な入力信号のファイル又はメモリに基づく入力から供給されても良い。開示されたシステムのいくつかは、クラウド対応サーバ技術を利用して動作しても良い。本願におけるコントローラ又はプロセッサという用語は、マイクロプロセッサ、マイクロコンピュータ、ＡＳＩＣ及び専用ハードウェア・コントローラを含むことを意図する。本開示の１つ以上の態様は、１つ以上のコンピュータ（モニタリング・モジュールを含む）その他のデバイスによって実行される、１つ以上のプログラム・モジュールのような、コンピュータ利用可能なデータ及びコンピュータ実行可能な命令で実現できる。一般に、プログラム・モジュールとしては、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含み、これらは、コンピュータその他のデバイス内のプロセッサによって実行されると、特定のタスクを実行するか、又は、特定の抽象データ形式を実現する。コンピュータ実行可能命令は、ハードディスク、光ディスク、リムーバブル記憶媒体、ソリッド・ステート・メモリ、ＲＡＭなどのコンピュータ可読記憶媒体に記憶しても良い。当業者には理解されるように、プログラム・モジュールの機能は、様々な態様において必要に応じて組み合わせられるか又は分散されても良い。更に、こうした機能は、集積回路、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）などのようなファームウェア又はハードウェア同等物において、全体又は一部を具体化できる。特定のデータ構造を使用して、本発明の１つ以上の態様をより効果的に実施することができ、そのようなデータ構造は、本願に記載されたコンピュータ実行可能命令及びコンピュータ使用可能データの範囲内と考えられ、コンピュータ使用可能データは、コンピュータ・プログラム・プロダクトと呼んでも良い。コンピュータ可読媒体は、上述のように本願で説明された。

開示された態様は、場合によっては、ハードウェア、ファームウェア、ソフトウェア又はそれらの任意の組み合わせで実現されても良い。開示された態様は、１つ以上のプロセッサによって読み取られ、実行され得る１つ又は複数のコンピュータ可読媒体によって運搬されるか又は記憶される命令として実現されても良い。そのような命令は、本願では、コンピューティング装置によってアクセス可能な任意の媒体を意味する。限定するものではないが、一例としては、コンピュータ可読媒体は、コンピュータ記憶媒体及び通信媒体を含むことができる。

コンピュータ記憶媒体は、コンピュータ読み取り可能な情報を記憶するために使用することができる任意の媒体を意味する。限定するものではないが、例としては、コンピュータ記憶媒体としては、ランダム・アクセス・メモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、電気消去可能プログラマブル読み出し専用メモリ（ＥＥＰＲＯＭ）、フラッシュメモリやその他のメモリ技術、コンパクト・ディスク読み出し専用メモリ（ＣＤ-ＲＯＭ）、ＤＶＤ（Digital Video Disc）やその他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置やその他の磁気記憶装置、及び任意の技術で実装された任意の他の揮発性又は不揮発性の取り外し可能又は取り外し不能の媒体を含んでいても良い。コンピュータ記憶媒体としては、信号そのもの及び信号伝送の一時的な形態は排除される。

通信媒体は、コンピュータ可読情報の通信に利用できる任意の媒体を意味する。限定するものではないが、例としては、通信媒体には、電気、光、無線周波数（ＲＦ）、赤外線、音又はその他の形式の信号の通信に適した同軸ケーブル、光ファイバ・ケーブル、空気又は任意の他の媒体を含むことができる。

開示された主題の上述のバージョンは、記述したか又は当業者には明らかであろう多くの効果を有する。それでも、開示された装置、システム又は方法のすべてのバージョンにおいて、これらの効果又は特徴のすべてが要求されるわけではない。

加えて、本願の記述は、特定の特徴に言及している。本明細書における開示には、これらの特定の特徴の全ての可能な組み合わせが含まれると理解すべきである。ある特定の特徴が特定の態様又は実施例の状況において開示される場合、その特徴は、可能である限り、他の態様及び実施例の状況においても利用できる。

また、本願において、２つ以上の定義されたステップ又は工程を有する方法に言及する場合、これら定義されたステップ又は工程は、状況的にそれらの可能性を排除しない限り、任意の順序で又は同時に実行しても良い。

説明の都合上、本発明の具体的な実施例を図示し、説明してきたが、本発明の要旨と範囲から離れることなく、種々の変更が可能なことが理解できよう。従って、本発明は、添付の特許請求の範囲を除いて限定されるべきではない。

１０ 試験測定システム
１４ プロセッサ
１６ メモリ
１８ 入力端子
２０ 物理媒体入力ライン
２２ ユーザ・インタフェース
２４ 出力ライン
３０ プロトコル宣言
４０ パーサ
５０ 物理的入力信号
６０ 構文木
７０ ビットストリーム
９０ パケット・ビットストリーム・データ
１００ プリアンブル・ステージ
１０２ ビットストリーム定義
２００ イベント探索ステージ
２０２ イベント定義
３００ フィールド・マッピング・ステージ
３０２ フィールド定義
７０２ 標準デコーダ
７５０ 物理的な入力信号s
７７０ 未加工ビットストリーム
７７２ ライン・コード・エンコーディング・ライブラリ
７８２ フィールド・デバイス・アクセス（ＦＤＡ）及びデバイス記述言語（ＤＤＬ）ライブラリ
７３０ プロトコル宣言
７０６ コンパイラ
７６０ 構文木
７８０ ビットストリーム・フレーミング・データ
７９０ パケット化ビットストリーム・データ
７１４ パケット・コレクション
７１６ ペイロード抽出
７１２ ＣＲＣチェック
７１８ メディア・ファイル
７２０ データ・ストア

Claims (10)

1. ライン・コード化物理的信号を受ける物理的チャンネル入力部と、
   宣言型言語定義から生成された構文木（syntax tree）を記憶するメモリと、
   該メモリと動作可能に結合され、上記構文木にアクセスし、上記ライン・コード化物理的信号から時間及びエッジ・データを抽出し、上記構文木の状態に基づいて抽出された上記時間及びエッジ・データを用いてビットストリームに関するビット値を生成するよう構成されるプロセッサと
   を具える試験及び測定に適したコンピューティング装置。
2. 上記プロセッサが、更に、
   上記宣言型言語定義内のイベント開始及び終了定義に基づいて上記ビットストリームから時間マーカを抽出し、
   抽出された上記時間マーカに基づいて上記構文木を用いて上記ビットストリームについてのパケット・フレームを生成するように構成される請求項１のコンピューティング装置。
3. 上記プロセッサが、更に、
   上記宣言型言語定義内のフィールド定義に基づいて、生成された上記パケット・フレーム内にフィールドをマッピングし、
   マッピングされた上記フィールドに基づいて、上記構文木を用いて上記ビットストリームについてのパケットを生成するよう構成される請求項２のコンピューティング装置。
4. 構文木を用いて物理的な入力信号を解釈する方法であって、
   宣言型言語定義を読み出す処理と、
   上記宣言型言語定義に基づいて上記構文木をコンパイルする処理と、
   上記構文木のノードを用いて上記物理的な入力信号のライン・コード・エンコーディングをデコードすることによって、上記物理的な入力信号をビットストリームへ変換する処理と
   を具える方法。
5. イベント開始及び終了定義に基づいて、上記構文木を用いて上記ビットストリームについてのパケット・フレームを生成する処理を更に具える請求項４の方法。
6. フィールド定義に基づいて、上記構文木を用いて上記ビットストリームについてのパケットを生成する処理を更に具える請求項５の方法。
7. メディア・ファイルを出力するため、トークン交換を用いて上記ビットストリームのパケットからペイロードを抽出する処理を更に具え請求項６の方法。
8. 試験及び測定に適したコンピューティング装置中のプロセッサで実行されたときに、上記コンピューティング装置に、
   ビットストリーム定義、イベント定義及びフィールド定義の中の１つ以上を含むプロトコル宣言に基づいて構文木をコンパイルさせ、
   物理的な信号を受けるようにさせ、
   上記構文木を用いて上記物理的な信号をビットストリームにデコードさせる
   コンピュータ・プログラム。
9. 更に、上記ビットストリーム定義を供給するために、上記コンピューティング装置に、ライン・コード・エンコーディング・ライブラリを利用させる請求項８のコンピュータ・プログラム。
10. 更に、上記イベント定義又はフィールド定義を供給するために、上記コンピューティング装置に、フィールド・デバイス・アクセス及びデバイス記述言語ライブラリを利用させる請求項８のコンピュータ・プログラム。