ホーム > 特許ランキング > ＴＥＫＴＲＯＮＩＸ，ＩＮＣ．
特許7364580試験測定装置のためのプロトコル・デザイナ及びプロトコル定義を生成、デバッグ及び展開する方法
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-10-10
(45)【発行日】2023-10-18
(54)【発明の名称】試験測定装置のためのプロトコル・デザイナ及びプロトコル定義を生成、デバッグ及び展開する方法
(51)【国際特許分類】
G06F 11/36 20060101AFI20231011BHJP
【ＦＩ】
G06F11/36 164
G06F11/36 136
【請求項の数】
7
(21)【出願番号】P 2020549062
(86)(22)【出願日】2019-03-13
(65)【公表番号】
(43)【公表日】2021-08-02
(86)【国際出願番号】 US2019022038
(87)【国際公開番号】W WO2019178219
(87)【国際公開日】2019-09-19
【審査請求日】2022-03-03
(31)【優先権主張番号】62/642,011
(32)【優先日】2018-03-13
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】391002340
【氏名又は名称】テクトロニクス・インコーポレイテッド
【氏名又は名称原語表記】ＴＥＫＴＲＯＮＩＸ，ＩＮＣ．
(74)【代理人】
【識別番号】100090033
【弁理士】
【氏名又は名称】荒船 博司
(74)【代理人】
【識別番号】100093045
【弁理士】
【氏名又は名称】荒船 良男
(74)【代理人】
【識別番号】110001209
【氏名又は名称】特許業務法人山口国際特許事務所
(72)【発明者】
【氏名】マーク・エイ・スミス
(72)【発明者】
【氏名】マイケル・スコット・シリマン
(72)【発明者】
【氏名】アンドリュー・ルーフバロー
(72)【発明者】
【氏名】エリック・ティ・アンダーソン
【審査官】武田 広太郎
(56)【参考文献】
【文献】特開２０１０－２６７２６６（ＪＰ，Ａ）
【文献】特表２０１８－５１８７６２（ＪＰ，Ａ）
【文献】特開２０１３－１０６３５６（ＪＰ，Ａ）
【文献】日下志 友彦，仕様の記述からコードの自動生成まで実現可能な プロトコル仕様記述言語ＣＭＤＬによる通信プロトコル設計，Ｉｎｔｅｒｆａｃｅ 第３０巻 第２号 ，日本，ＣＱ出版株式会社，2004年
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｆ １１／３６
(57)【特許請求の範囲】
【請求項1】
試験測定装置のためのプロトコル・デザイナであって、信号を受ける入力部と、
上記信号を記憶するように構成されたメモリと、
ユーザの入力に基づいてプロトコル定義を生成するように構成されたオーサと、
上記プロトコル定義と上記信号とに基づいて、文字で及び視覚的にデコード結果を出力するように構成されたデバッガと、
上記試験測定装置にコンパイルされたプロトコル定義ファイルを出力するように構成されたデプロイヤと
を具え、
上記デバッガが、上記プロトコル定義に基づいて、上記信号中のイベントとフィールドのマッチングをタイミング情報と共に生成するように更に構成される試験測定装置のためのプロトコル・デザイナ。
【請求項2】
試験測定装置のためのプロトコル・デザイナであって、信号を受ける入力部と、
上記信号を記憶するように構成されたメモリと、
ユーザの入力に基づいてプロトコル定義を生成するように構成されたオーサと、
上記プロトコル定義と上記信号とに基づいて、文字で及び視覚的にデコード結果を出力するように構成されたデバッガと、
上記試験測定装置にコンパイルされたプロトコル定義ファイルを出力するように構成されたデプロイヤと
を具え、
上記デバッガは、イベントが検出されたときに、上記信号のデコードを停止するように更に構成される試験測定装置のためのプロトコル・デザイナ。
【請求項3】
上記デバッガは、上記プロトコル定義に基づいて、上記信号をデコードし、デコードされた上記信号内の特定のイベントを検索するように更に構成される請求項１のプロトコル・デザイナ。
【請求項4】
コンピュータ・プログラムであって、プロトコル・デザイナの１つ以上のプロセッサによって実行されると、上記プロトコル・デザイナに、信号を受けさせ、
信号を記憶させ、
ユーザの入力に基づいてプロトコル定義を生成させ、
上記プロトコル定義及び上記信号に基づいて文字で及び視覚的にデコード結果を出力させ、
上記プロトコル定義に基づいて、上記信号中のイベントとフィールドのマッチングをタイミング情報と共に生成させ、
ユーザの入力に基づいてコンパイル済みプロトコル定義ファイルを生成させ、
上記コンパイル済みプロトコル定義ファイルを試験測定装置に出力させる
命令を含むコンピュータ・プログラム。
【請求項5】
コンピュータ・プログラムであって、プロトコル・デザイナの１つ以上のプロセッサによって実行されると、上記プロトコル・デザイナに、信号を受けさせ、
信号を記憶させ、
ユーザの入力に基づいてプロトコル定義を生成させ、
上記プロトコル定義及び上記信号に基づいて文字で及び視覚的にデコード結果を出力させ、
イベントが検出されたときに、上記信号のデコードを停止させ、
ユーザの入力に基づいてコンパイル済みプロトコル定義ファイルを生成させ、
上記コンパイル済みプロトコル定義ファイルを試験測定装置に出力させる
命令を含むコンピュータ・プログラム。
【請求項6】
アナログ信号を受ける処理と、上記アナログ信号を記憶する処理と、
ユーザの入力に基づいてプロトコル定義を生成する処理と、
上記プロトコル定義と上記アナログ信号に基づいて、上記アナログ信号中のイベント及びフィールドのマッチングをタイミング情報と共に生成することにより、文字で及び視覚的にデコード結果を出力する処理と、
ユーザの入力に基づいてコンパイル済みプロトコル定義ファイルを生成する処理と、
上記コンパイル済みプロトコル定義ファイルを試験測定装置に展開する処理と
を具える試験測定装置のためのプロトコル定義を生成、デバッグ及び展開する方法。
【請求項7】
アナログ信号を受ける処理と、上記アナログ信号を記憶する処理と、
ユーザの入力に基づいてプロトコル定義を生成する処理と、
上記プロトコル定義と上記アナログ信号に基づいて、文字で及び視覚的にデコード結果を出力する処理と、
イベントが検出されたときに、上記アナログ信号のデコードを停止する処理と、
ユーザの入力に基づいてコンパイル済みプロトコル定義ファイルを生成する処理と、
上記コンパイル済みプロトコル定義ファイルを試験測定装置に展開する処理と
を具える試験測定装置のためのプロトコル定義を生成、デバッグ及び展開する方法。
【発明の詳細な説明】
【技術分野】
【0001】
本開示技術は、２０１８年３月１３日に出願された米国仮出願番号第６２/６４２,０１１号、発明の名称「プロトコルの設計、評価、デバッグのための統合開発環境」の利益を主張するものであり、これは、言及することにより、その全体が本願に組み込まれている。
【0002】
本開示技術は、試験測定システムに関連するシステムと方法、特に、試験測定装置のためのプロトコルの定義を作成、デバッグ及び展開することに関する。
【0003】
電子通信システムでは、情報は、通常、特定のプロトコルに従ってパケットの形で送信される。プロトコル・スタックは、階層化された構成で、複数の異なるプロトコルから構成される。例えば、最初の層（レイヤ）は、物理層で、これは、構造化されていないビットストリーム（その波形）の伝送を含む。第２層は、データ・リンク層であっても良く、これは、エラーのない伝送を保証する。第３層は、アドレス指定及び制御用のネットワーク層であっても良い。第４層は、データのトランスポート用のトランスポート層であっても良い。第５層は、接続を確立、管理、及び終了するためのセッション層であっても良い。最後に、第６層は、データの暗号化、圧縮及び再フォーマットなど、データの意味のある交換のためのプレゼンテーション層であっても良い。情報は、物理層で、１と０のシーケンスを表すアナログ信号として送信される。次いで、アナログ・データは、デジタルの等価なものに変換され、定義されたプロトコルに従ってデコードされる。
【先行技術文献】
【特許文献】
【0004】
【文献】米国特許公開第２００７／００３０８１２号明細書
【文献】米国特許公開第２００８／０１４４６５６号明細書
【発明の概要】
【発明が解決しようとする課題】
【0005】
現在、従来のプロトコル・デザイナ（protocol designer：プロトコル・デザイン・ツール）は、プロトコル定義ファイルのオーサリングや作成と、コンパイラを用いてそのプロトコルが言語的に正しいかを検証するためのオプションを提供できるだけである。他方において、試験測定装置用の従来のプロトコル・デザイナは、デコード結果のデバッグ支援や、アナログ・シリアル・バス・ソースの物理層の解釈に関する情報は提供しない。
【0006】
本開示技術の実施形態は、これら及び他の従来技術の欠陥に対処する。
【0007】
本開示技術の実施形態の態様、特徴及び効果は、次の添付図面を参照した実施形態の説明から明らかになるであろう。
【図面の簡単な説明】
【0008】
【発明を実施するための形態】
【0009】
上述したように、プロトコル定義を作成するための現在のツールは、プロトコル定義を作成し、プロトコル定義の言語の正しさを検証するためのオプションのみを提供する。しかし、現在のツールでは、プロトコル定義が信号中のパケットやデータを正しく検出していることを確認するなど、作成されたプロトコル定義について、テキストのデバッグや視覚的なデバッグを更に行うことはできない。つまり、既存のプロトコル定義ツールは、デコード結果のデバッグに役立たないし、アナログ・シリアル・バス・ソースの物理層の解釈に関する情報も提供しない。
【0010】
一方、本開示技術の実施形態は、グラフィカル及びテキストの両方から追加の情報を提供し、プロトコル定義で起こりうる問題をユーザが特定するのを助ける。例えば、本開示技術の実施形態には、ユーザがプロトコル定義をインタラクティブにデバッグするのを可能にするための、物理層ビットストリーム出力、デコーダのデバッグ出力、タイミング情報、並びに、時間を相関させた入力ソース及びデコード結果の視覚的表示がある。また、本開示技術の実施形態は、以下で更に詳細に説明するように、システムを利用可能な状況にする（deployment：展開する）オーサリングからデバッグまでの完全な開発環境を提供する。
【0011】
図１は、本願に開示される本開示技術の実施形態を実施するためのプロトコル・デザイナ１００の例のブロック図である。プロトコル・デザイナ１００は、例えば、統合的な（integrated）デザイン環境であっても良い。プロトコル・デザイナ１００には、１つ以上のポート１０２がある。ポート１０２は、有線又は無線のいずれかで、データを受ける任意のデバイスを含めることができる。ポート１０２は、プロセッサ１０４に接続され、これは、後述するように、本開示技術の実施形態を実施するための種々のコンポーネントを含む。図１では、説明を簡単にするため、１つのプロセッサ１０４が示されているが、当業者であればわかるように、単一プロセッサ１０４ではなく、異なる形式の複数のプロセッサ１０４を組み合わせて使用しても良い。
【0012】
ポート１０２は、ポート１０２を通して受けたデータを格納するためのメモリ１０６に接続されていても良い。また、メモリ１０６は、１つ以上のプロセッサ１０４によって実行される命令を、こうした命令によって示される方法、動作や関連するステップを実行するために格納しても良い。例えば、メモリ１０６は、既知のアナログ信号に対するプロトコル定義の結果を視覚的に表示することを含め、プロトコルをオーサリングし、プロトコルをデバッグする命令を有していても良い。当業者であればわかるように、メモリ１０６としては、限定するものではないが、プロセッサ・キャッシュ、ランダム・アクセス・メモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、ソリッド・ステート・メモリ、ハード・ディスク・ドライブ又はその他のメモリ形式のような１つ以上のメモリを含んでいても良い。
【0013】
ユーザ入力部１０８は、１つ以上のプロセッサ１０４に結合される。ユーザ入力部１０８としては、表示部１１０上のグラフィカル・ユーザ・インターフェース（ＧＵＩ）に対してインタラクティブにユーザが利用できるキーボード、マウス、トラックボール、タッチスクリーンその他の任意の操作手段を含んでいても良い。表示部１１０は、波形、測定値その他のデータをユーザに表示するデジタル・スクリーン、陰極線管ベースのディスプレイその他のモニタであっても良い。プロトコル・デザイナ１００のコンポーネント（構成要素）は、プロトコル・デザイナ１００内に統合されて描かれているが、当業者であればわかるように、これらのコンポーネントは、いずれもプロトコル・デザイナ１００の外部にあっても良く、任意の在来のやり方（例えば、有線又は無線の通信メディア又はメカニズム）でプロトコル・デザイナ１００に結合されていても良い。例えば、実施形態によっては、表示部１１０は、プロトコル・デザイナ１００から遠隔（リモート）にあっても良い。
【0014】
プロセッサ１０４に戻ると、プロセッサ１０４は、オーサ（author）１１２を含んでいても良い。オーサ１１２は、ユーザが、米国特許公開第２００７／００３０８１２号（これは、言及することで、その全体が本願に組み込まれる）が教えるようなプロトコル定義ファイルを作成や編集できるように構成できる。また、プロセッサ１０４は、デバッガ１１４を含んでいても良い。デバッガ１１４は、以下で詳しく説明されるように、複数のテキスト的及び視覚的なスキームを通じて、プロトコル定義のデバッグ及びデコード結果の洗練化（refinement：微調整）のためのオプションを提供する。プロセッサ１０４は、また、オシロスコープ、ロジックアナライザなどの試験測定装置に、プロトコル定義ファイルを展開する（deploy：配置する、利用可能な状態にする）、即ち、出力及び転送するデプロイヤ（deployer）１１６を含んでもよい。プロセッサ１０４には、ランタイム・エンジンも含まれる。いくつかの実施形態では、ランタイム・エンジンは、デバッガ１１４の一部として提供される。このランタイム・エンジンは、宣言型デコード言語（declarative decode language：DDL）ランタイム・エンジンと呼んでも良く、プロトコル定義とポート１０２からの受信信号やメモリ１０６に保存された信号とに基づいてデコード結果を生成する。
【0015】
図２は、プロトコル・デザイナ１００に関する表示部１１２上のグラフィカル・ユーザ・インタフェースの出力例を示す。グラフィカル・ユーザ・インタフェース２００には、受信波形やプロトコル・エディタなどの異なる情報を表示する様々なウィンドウ２０２があっても良い。グラフィカル・ユーザ・インタフェース２００は、展開する装置の種類、ビューア、保存されたプロトコルなどをユーザが選択できるように、様々なメニューを含むことができる。このグラフィカル・ユーザ・インタフェース２００は、オーサ１１２、デバッガ１１４及びデプロイヤ１１６を使って、上述のように、プロトコル定義ファイルを作成（author）、デバッグ及び展開するのに利用できる。
【0016】
グラフィカル・ユーザ・インタフェース２００には、デバッガ１１４からの各種デコード出力を表示するためのウィンドウ２０４がある。グラフィカル・ユーザ・インタフェース２００には、更に、現在のシステムに何があるかと、どんな装置、ビューア及びプロトコルをシステムに追加できるかとを表示する様々なメニュー２０６及び２０８がある。
【0017】
図３は、デバッガ１１４の機能の１つの例を示す。図３は、グラフィカル・ユーザ・インタフェース２００の一部を示す。プロトコル定義が、オーサ１１２を用いてドメイン固有言語（domain-specific language）で記述された後、デバッガ１１４はコンパイラを通じてプロトコル定義を実行する。コンパイラの出力は、ユーザが分析するために、ウィンドウ２０４に表示されても良い。コンパイラは、プロトコル定義ファイル中の、非宣言識別子（undeclared identifier）のようなプロトコル定義の構文（シンタックス）エラーを、例えば、プロトコル定義ソース・コード中のそのエラーの行及び列番号を与えることによって、それらの位置と合わせて特定する。
【0018】
ソース・コードのエラーの迅速な特定を支援するように、デバッガ１１４は、ウィンドウ２０４において、コンパイラで生成されたエラーを強調表示又は別の方法で特定（識別）できる。コンパイラで生成されたエラーをユーザが選択すると、デバッガ１１４は、ウィンドウ２０２中に、対応するソース・ファイルを、規範違反のエラーが強調表示された３０２と共に表示させることができる。例えば、図３に示すように、シンタックス（構文）エラーは、ウィンドウ２０４中の３００で識別され、プロトコル定義中のエラーは、３０２で強調表示されるので、ユーザは、エラーがどこに存在するかを迅速に判断し、エラーを修正できる。
【0019】
図４は、デバッガ１１４の更に別の機能を示す。デバッガ１１４のランタイム・エンジンは、１つ以上のプロセッサ１０４によって動作されても良く、プロトコル定義のイベント及びフィールドのマッチング（一致）を示すデバッグ出力データを、これらマッチングのタイミング（時間）情報と共に生成できる。上述のように、既知のデータを、１つ以上のポート１０２を通してメモリ１０６に供給しても良い。
【0020】
図４に示すように、デコード出力ウィンドウ２０４は、既知の信号のイベント及びフィールドのマッチングを示すデータを、タイミング情報と共に有していて良い。ユーザは、このデータを既知の入力データと比較して、プロトコル定義が正しく機能しているか、又は予期したとおりに機能しているかを判断できる。つまり、プロトコル定義が、既知の入力データ内のフィールド及びイベントのポイント（場所）を正しく識別（特定）しているか、ということである。ユーザは、プロトコル定義内にオプションの出力（OUTPUT）コマンドを挿入することにより、これらのデバッグ出力を更に増やすことができる。
【0021】
デバッガ１１４は、また、デコード動作に加えて、その基礎となる物理層のビットストリーム変換の両方の出力を可能にしてもよい。ビットストリーム情報は、生のアナログ入力信号を、クロック信号、クロック・リカバリ及び他の符号化（encoding）メカニズムを使用して、デジタル・ビットのシリアル・シーケンスに変換したものである。図５は、ウィンドウ２０４にビットストリーム出力を示し、これは、ユーザが既知の入力信号と比較するために、デジタル・ビットのシリアル・シーケンスをタイミング情報と共に出力している。これにより、ユーザは、作成されたプロトコル定義を使用したビットストリームの変換が、期待されるビットシーケンスを生じているかを確認できる。無効なビット・シーケンスは、入力信号中のタイミング・エラーを示しているか、又は、プロトコル定義のビットストリーム変換定義のアルゴリズム・エラーを示している可能性がある。
【0022】
図５のウィンドウ２０４において、ビットストリームのデバッガ１１４の出力は、ソースのビットに変換するタイミングを示す。いくつかの実施形態では、プロトコル・デザイナ１００が、一般的に使用される様々な物理層符号化スキームをサポートするプロトコル定義のライブラリをデフォルトで有していても良い。ストックのプロトコル定義ライブラリは、例えば、メモリ１０６に記憶されても良い。プロトコル定義ライブラリは、カスタムな定義に加えて、限定するものではないが、ノン・リターン・トゥ・ゼロ（ＮＲＺ）、マンチェスター、ＭＬＴ３（multi-level transmit 3）のような物理層の符号化スキームをサポートしていても良い。これは、ストックの物理層定義のいずれかを再利用するのではなく、ドメイン固有言語を使用して、独自の物理層定義を作成したユーザにとって特に有益であろう。
【0023】
プロトコル・イベント定義は、パケットの先頭と末尾を識別（特定）するための主要な手段である。その結果として、プロトコル定義において、適切なイベント定義とタイミング特性を識別するツールは重要である。こうしたことから、デバッガ１１４は、関心のあるイベントが検出されたときに、ランタイム・デコード処理を停止して、そのイベントをユーザに出力する機能と、発生した時刻とを提供しても良い。例えば、ユーザは、イベントＳにブレークポイントを設定し、入力データ内で、このイベントが最初に検出された場所を確認できる。いくつかの実施形態では、デバッガ１１４が、入力データ内の全てのイベントを検索しても良い。デバッガ１１４は、ランタイムを停止せずに、ユーザによって指定された各イベントを見つけることによって、ランタイム・エンジンが、データ・レコード全体を通して、イベントをどのように解釈するかについて静的な評価を提供できる。
【0024】
いくつかの実施形態では、図６に示すように、デバッガ１１４は、ウィンドウ２０２を利用して、マッチングしたイベントを使って、入力データに注釈を付けることができる。例えば、イベントＳのパケット６００は、入力データ６０２とマッチングしており、入力データ６０２で特定される。図６に示す例では、「Ｃｈ.１」と「Ｃｈ.２」というラベルの波形が、それぞれシリアル通信バスのクロック信号とデータ信号であっても良い。これにより、ユーザは、イベントのランタイム評価を、既知のデータ入力に対して視覚的に位置を一致させて、プロトコル定義が期待どおりに動作しており、プロトコル定義にエラーがないことを確認できる。
【0025】
図７～９に示すように、デバッガ１１４によって、ユーザは、パケット検出処理全体を、段階（ステップ）を踏んで実行し、結果をデコードできる。デバッガ１１４によって、ユーザは、入力波形全体をシーケンス処理し（sequence）、ランタイム・エンジンが各パケット・シーケンスをどのように解釈しているかを確認できる。図７に示すように、入力波形７０２に関連する最初のパケット７００がウィンドウ２０２に表示される。入力波形と、デコードされたパケット７００の開始位置とを揃えるためにカーソルが表示され、それによって、デコードされたパケットと入力波形との間の時間的な相互関係を表示する。図８では、ユーザが入力波形７０２に沿ってカーソルを移動させており、入力波形中のその時点で新しいパケット８００が示されている。ユーザは、入力波形を通して、スクロールを続けることができ、図９に示すように、次のパケット９００が、その波形に入ったときに表示される。
【0026】
いくつかの実施形態では、ユーザは、各パケットの検出に進むボタンを選択しても良い。ボタンが最初に押されると、パケット７００と、最初のパケット７００の入力波形上のカーソルとが表示されることになろう。ボタンが再度押されると、次のパケット８００が表示され、カーソルは、入力波形上で、次のパケット８００の位置に移動する。これが、入力波形の終わりまで続く。
【0027】
また、いくつかの実施形態では、ユーザは、デバッガ１１４で「ここからデコード」のオプションを選択して、波形表示内の任意の時間を選択し、ランタイム・デコーダ又はエンジンが、この時間の後からデコードの評価を始める。これにより、イベントが始まる複数のパケットをエンコードするプロトコル仕様を扱う場合に、より高速な分析とデバッグ時間を提供できる。
【0028】
デバッガ１１４には、更に、オーバーレイ・オプションがあっても良い。このオプションがユーザによって選択されると、デバッガ１１４は、図１０に示すように、入力データ１０００とデコード結果１００２をオーバーレイ（重ね合わせ）表示として表示する機能を提供する。このオーバーレイ表示は、互いの上に直接重ね合わせて配置することも、各ソースが垂直方向にわずかにオフセットされるように調整することもできる。即ち、入力データ１０００とデコード結果１００２のオーバーレイ表示は、完全にオーバーレイされる必要はなく、互いにオフセットされても良い。図１０に示すように、これによれば、入力信号とそのタイミングが、プロトコル定義を使用してランタイム・エンジンによってどのように解釈されているかを、ユーザが確認する機能を高めることができる。従って、ユーザは、この情報を使用し、必要に応じて、所望の結果を得るように、プロトコル定義を変更できる。
【0029】
デバッガ１１４は、また、目的のポイントを見つけるためのカーソルやマーク、カーソル間の時間差を測定するためのツール、デコードされた結果を素早く見つけるための検索／フィルタ・オプション、異なる基数（radix）表示オプションなど、デコード結果の定義及び評価を支援する追加の機能を備えてもよい。
【0030】
上述のように、プロトコル・デザイナ１００には、更に、デプロイヤ１１６があっても良い。ユーザが、オーサ１１２やデバッガ１１４を使用して、完全なプロトコル定義を生成したら、デプロイヤ１１６は、図１１に示すように、プロトコル定義を試験測定装置１１００に送信できる。即ち、プロトコル・デザイナ１００によれば、ユーザは、試験測定装置１１００のコアのファームウェアに変更を加えることなく、試験測定装置１１００内で実行できる完全なプロトコル・ソリューションを形成し、完全にデバッグできる。試験測定装置１１００が、プロトコル・デザイナ１００に含まれるのと同じランタイム・エンジンを有していても良い。言い換えれば、開示技術の実施形態は、試験測定装置１１００が、試験測定装置１１００のコアのコード・ベースに何らの変更も加えることなく、全く新しい又は独自のプロトコルに対するデコードやイベント検索サポートを提供することを可能にする。試験測定装置１１００のコード・ベースは、典型的には非常に複雑であるため、コード・ベースの修正及び必要なテストは、一般に、時間がかかり、高価で、エラーが起こりやすい。従って、開示技術の実施形態は、新しいか又はカスタムのプロトコルをサポートし、市場投入までの時間及びコストを大幅に改善する。
【0031】
試験測定装置１１００は、プロトコル・デザイナ１００と同じ記述定義言語（ＤＤＬ：description definition language）ランタイム・エンジン１１０２を含んでいても良い。試験測定装置１１００には、更に、試験測定装置１１００に入力される任意の信号を分析するための分析部１１０４、宣言型ユーザ・インタフェース・レイアウト１１０６があっても良い。
【0032】
プロトコル・デザイナ１００のデプロイヤ（deployer）１１６は、プロトコル・デコード・オプションの構成や設定メニューを含む宣言型ユーザ・インタフェース・ファイル１１０８を生成及び送信できる。いくつかの実施形態では、宣言型ユーザ・インタフェース・ファイル１１０８が、ＱＭＬ（Qt Modeling Language）を使用しても良い。また、デプロイヤ１１６は、問い合わせ言語（query language）、プロトコル表示プロパティ及び検索定義を定義する宣言型定義ファイル１１１０を生成し、送信することもできる。いくつかの実施形態では、宣言型定義ファイル１１１０が、拡張マークアップ言語（ＸＭＬ）を使用しても良い。また、デプロイヤ１１６は、ＤＤＬランタイム・エンジン１１０２によって実行される、コンパイル済みプロトコル定義ファイル１１１２、つまり、ＤＤＬ定義ファイルを出力することもできる。
【0033】
上述のように、本開示技術の実施形態は、プロトコル・デザイナがプロトコル定義を作成可能とするだけでなく、プロトコル定義をデバッグして試験測定装置に展開（deploy）できるので有益である。これにより、ユーザは、生成したプロトコル定義が期待どおりに動作しているか確認し、試験測定装置上で追ってデータを分析し、被試験デバイスが期待どおりに動作しているかを確認できる。以前のプロトコル・デザイナとプロトコル定義のための統合設計環境では、ユーザは、プロトコル定義の生成だけは可能だったが、本開示技術の実施形態を使用して実行できるような、プロトコル定義の広範なデバッグは実行できなかった。
【0034】
本開示技術の態様は、特別に作成されたハードウェア、ファームウェア、デジタル・シグナル・プロセッサ又はプログラムされた命令に従って動作するプロセッサを含む特別にプログラムされた汎用コンピュータ上で動作できる。本願における「コントローラ」又は「プロセッサ」という用語は、マイクロプロセッサ、マイクロコンピュータ、ＡＳＩＣ及び専用ハードウェア・コントローラ等を意図する。本開示技術の態様は、１つ又は複数のコンピュータ（モニタリング・モジュールを含む）その他のデバイスによって実行される、１つ又は複数のプログラム・モジュールなどのコンピュータ利用可能なデータ及びコンピュータ実行可能な命令で実現できる。概して、プログラム・モジュールとしては、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含み、これらは、コンピュータその他のデバイス内のプロセッサによって実行されると、特定のタスクを実行するか、又は、特定の抽象データ形式を実現する。コンピュータ実行可能命令は、ハードディスク、光ディスク、リムーバブル記憶媒体、ソリッド・ステート・メモリ、ＲＡＭなどのコンピュータ可読記憶媒体に記憶しても良い。当業者には理解されるように、プログラム・モジュールの機能は、様々な実施例において必要に応じて組み合わせられるか又は分散されても良い。更に、こうした機能は、集積回路、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）などのようなファームウェア又はハードウェア同等物において全体又は一部を具体化できる。特定のデータ構造を使用して、本開示技術の１つ以上の態様をより効果的に実施することができ、そのようなデータ構造は、本願に記載されたコンピュータ実行可能命令及びコンピュータ使用可能データの範囲内と考えられる。
【0035】
開示された態様は、場合によっては、ハードウェア、ファームウェア、ソフトウェア又はこれらの任意の組み合わせで実現されても良い。開示された態様は、１つ以上のプロセッサによって読み取られ、実行され得る１つ又は複数のコンピュータ可読媒体によって運搬されるか又は記憶される命令として実現されても良い。そのような命令は、コンピュータ・プログラム・プロダクトと呼ぶことができる。本願で説明するコンピュータ可読媒体は、コンピューティング装置によってアクセス可能な任意の媒体を意味する。限定するものではないが、一例としては、コンピュータ可読媒体は、コンピュータ記憶媒体及び通信媒体を含むことができる。
【0036】
コンピュータ記憶媒体とは、コンピュータ読み取り可能な情報を記憶するために使用することができる任意の媒体を意味する。限定するものではないが、例としては、コンピュータ記憶媒体としては、ランダム・アクセス・メモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、電気消去可能プログラマブル読み出し専用メモリ（ＥＥＰＲＯＭ）、フラッシュメモリやその他のメモリ技術、コンパクト・ディスク読み出し専用メモリ（ＣＤ-ＲＯＭ）、ＤＶＤ（Digital Video Disc）やその他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置やその他の磁気記憶装置、及び任意の技術で実装された任意の他の揮発性又は不揮発性の取り外し可能又は取り外し不能の媒体を含んでいても良い。コンピュータ記憶媒体としては、信号そのもの及び信号伝送の一時的な形態は排除される。
【0037】
通信媒体とは、コンピュータ可読情報の通信に利用できる任意の媒体を意味する。限定するものではないが、例としては、通信媒体には、電気、光、無線周波数（ＲＦ）、赤外線、音又はその他の形式の信号の通信に適した同軸ケーブル、光ファイバ・ケーブル、空気又は任意の他の媒体を含むことができる。
実施例
実施例
【0038】
以下では、本願で開示される技術の理解に有益な実施例が提示される。この技術の実施形態は、以下で記述する実施例の１つ以上及び任意の組み合わせを含んでいても良い。
【0039】
実施例１は、試験測定装置のためのプロトコル・デザイナであって、信号を受ける入力部と、信号を記憶するように構成されたメモリと、ユーザの入力に基づいてプロトコル定義を生成するように構成されたオーサと、プロトコル定義と信号とに基づいて文字で（textual：逐語的に）及び視覚的にデコード結果を出力するように構成されたデバッガと、試験測定装置にコンパイルされたプロトコル定義ファイルを出力するように構成されたデプロイヤとを具えている。
【0040】
実施例２は、実施例１のプロトコル・デザイナであって、デバッガは、プロトコル定義に基づいて、信号中のイベントとフィールドのマッチングを、タイミング情報と共に生成するように更に構成されている。
【0041】
実施例３は、実施例１又は２のいずれかのプロトコル・デザイナであって、信号はアナログ信号であり、デバッガは、上記アナログ信号と１つ以上のプロトコル定義とに基づいて、ビットストリームを生成するように更に構成されている。
【0042】
実施例４は、実施例１～３のいずれかのプロトコル・デザイナであって、デバッガは、イベントが検出されたときに、信号のデコードを停止するように更に構成されている。
【0043】
実施例５は、実施例１～４のいずれかのプロトコル・デザイナであって、このとき、デバッガは、プロトコル定義に基づいて、入力信号をデコードし、デコードされた入力信号内の特定のイベントを検索するように更に構成される。
【0044】
実施例６は、実施例１～６のいずれかのプロトコル・デザイナであって、このとき、デバッガは、プロトコル定義に基づいて、イベント・パケットを出力し、プロトコル・デザイナは、イベント・パケットの少なくとも一部と入力信号とを同時に表示するように構成された表示部を更に具えている。
【0045】
実施例７は、実施例６のプロトコル・デザイナであって、イベント・パケットの少なくとも一部を、入力信号にオーバーレイさせて表示するように表示部が更に構成されている。
【0046】
実施例８は、実施例１～７のいずれかのプロトコル・デザイナであって、デバッガは、プロトコル定義内の構文エラーを特定して強調表示するよう更に構成されている。
【0047】
実施例９は、１つ以上のコンピュータ可読記憶媒体であって、プロトコル・デザイナの１つ以上のプロセッサによって実行されると、プロトコル・デザイナに、信号を受けさせ、信号を記憶させ、ユーザの入力に基づいてプロトコル定義を生成させ、プロトコル定義及び信号に基づいて文字で（textual：逐語的に）及び視覚的にデコード結果を出力させ、ユーザの入力に基づいてコンパイル済みプロトコル定義ファイルを生成させ、コンパイル済みプロトコル定義ファイルを試験測定装置に出力させる命令を含んでいる。
【0048】
実施例１０は、実施例９の１つ以上のコンピュータ可読記憶媒体であって、上記命令は、プロトコル・デザイナに、更に、プロトコル定義に基づいて信号中のイベントとフィールドのマッチングをタイミング情報と共に生成させる。
【0049】
実施例１１は、実施例９及び１０のいずれかの１つ以上のコンピュータ可読記憶媒体であって、このとき、信号はアナログ信号であり、上記命令は、更に、プロトコル・デザイナにアナログ信号及び１つ以上のプロトコル定義に基づいてビットストリームを生成させる。
【0050】
実施例１２は、実施例９～１１のいずれかの１つ以上のコンピュータ可読記憶媒体であって、このとき、上記命令は、更に、イベントが検出されたときに、プロトコル・デザイナに信号のデコードを停止させる。
【0051】
実施例１３は、実施例９～１２のいずれかの１つ以上のコンピュータ可読記憶媒体であって、このとき、上記命令は、更に、プロトコル・デザイナに、プロトコル定義に基づいて入力信号をデコードさせ、デコードされた入力信号内で特定のイベントを検索させる。
【0052】
実施例１４は、実施例９～１３のいずれかの１つ以上のコンピュータ可読記憶媒体であって、このとき、上記命令は、更に、プロトコル・デザイナに、イベント・パケットの少なくとも一部と入力信号とを同時に表示させる。
【0053】
実施例１５は、実施例１４の１つ以上のコンピュータ可読記憶媒体であって、このとき、上記命令は、更に、プロトコル・デザイナに、イベント・パケットの少なくとも一部を、入力信号にオーバーレイさせて表示させる。
【0054】
実施例１６は、実施例９～１５のいずれかの１つ以上のコンピュータ可読記憶媒体であって、このとき、上記命令は、更に、プロトコル・デザイナに、プロトコル定義内の構文エラー（syntax errors：シンタックス・エラー）を特定させ、強調表示させる。
【0055】
実施例１７は、試験測定装置のためのプロトコル定義を生成、デバッグ及び展開する方法であって、アナログ信号を受ける処理と、アナログ信号を記憶する処理と、ユーザの入力に基づいてプロトコル定義を生成する処理と、プロトコル定義とアナログ信号に基づいて文字で（textual：逐語的に）及び視覚的にデコード結果を出力する処理と、ユーザの入力に基づいてコンパイル済みプロトコル定義ファイルを生成する処理と、コンパイル済みプロトコル定義ファイルを試験測定装置へ展開する処理とを具えている。
【0056】
実施例１８は、実施例１７の方法であって、このとき、文字で及び視覚的にデコード結果を出力する処理が、プロトコル定義に基づいて、信号中のイベント及びフィールドのマッチングをタイミング情報と共に生成する処理を更に含んでいる。
【0057】
実施例１９は、実施例１７又は１８のいずれかの方法であって、このとき、文字で及び視覚的にデコード結果を出力する処理が、アナログ信号及び１つ以上のプロトコル定義に基づいて、ビットストリームを生成する処理を更に含んでいる。
【0058】
実施例２０は、実施例１７～１９のいずれかの方法であって、イベント・パケットの少なくとも一部と入力信号とを同時に表示する処理を更に具えている。
【0059】
開示された主題の上述のバージョンは、記述したか又は当業者には明らかであろう多くの効果を有する。それでも、開示された装置、システム又は方法のすべてのバージョンにおいて、これらの効果又は特徴のすべてが要求されるわけではない。
【0060】
加えて、本願の記述は、特定の特徴に言及している。本明細書における開示には、これらの特定の特徴の全ての可能な組み合わせが含まれると理解すべきである。ある特定の特徴が特定の態様又は実施例の状況において開示される場合、その特徴は、可能である限り、他の態様及び実施例の状況においても利用できる。
【0061】
また、本願において、２つ以上の定義されたステップ又は工程を有する方法に言及する場合、これら定義されたステップ又は工程は、状況的にそれらの可能性を排除しない限り、任意の順序で又は同時に実行しても良い。
【0062】
説明の都合上、本発明の具体的な実施例を図示し、説明してきたが、本発明の要旨と範囲から離れることなく、種々の変更が可能なことが理解できよう。従って、本発明は、添付の特許請求の範囲を除いて限定されるべきではない。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】