(57)【特許請求の範囲】
【請求項１】
イオン源と、イオン検出器と、コンピュータシステムと通信を行なうデータ取得エンジンと、を備える質量分析装置を用いて質量分析計のデータを取得する方法であって、
前記取得エンジンにより、前記イオン検出器からデータを受信すること、
前記受信したデータの強度ピークを検出すること、
前記検出したピークに対して、前記取得エンジンにより、前記ピークに関する時間と強度との情報を含むデータを生成すること、及び
前記コンピュータシステムに、前記時間と強度との情報を含むデータを伝達すること、
を備え、
前記取得エンジンからの前記データは、バッファを備えるデータスループット最適化モジュールに送られ、
前記バッファは、受信したデータのバッファリング、フォーマット及びパケット化を行なって、パケット化したデータをプロトコルスタックに送り、
前記プロトコルスタックは、前記コンピュータシステムと通信するネットワークインターフェースに、前記パケット化したデータを送り、
前記バッファは複数のセグメントを備え、各セグメントは、所定数のビットからなる複数の部分として構成されるメモリーブロックにより規定され、
各セグメントの少なくとも１つのヘッダー部分が、前記セグメントの内容に関するヘッダー情報を含むヘッダーワード用に確保され、
各チャンクが前記セグメントの前記部分のうちの１つの部分を占めるような
前記時間と強度との情報を含むデータチャンクが、前記バッファの前記セグメントのうち最初の１つのセグメントにストリーミングされ、
前記最初の１つのセグメントが充填されると、データチャンクが前記バッファの次のセグメントにストリーミングされ、前記ヘッダー情報を含む前記セグメントのうちの最初の１つのセグメントのデータが前記プロトコルスタックに転送される、方法。
【請求項２】
請求項１に記載の方法であって、
前記バッファは、ＦＩＦＯ（First In First Out）バッファである、方法。
【請求項３】
請求項２に記載の方法であって、
前記バッファは、リングバッファである、方法。
【請求項４】
請求項１に記載の方法であって、
スキャン終了時に、前記取得エンジンにより、スキャン終了マーカーを含むスキャン終了ワードを生成し、
前記バッファは、１つのセグメントにストリーミングされたデータにスキャン終了マーカーが含まれている場合に、そのセグメントへのデータのストリーミングを終了し、以降のデータを前記バッファ内の次のセグメントにストリーミングし、前記最初のセグメント内のデータを前記最初のセグメントから前記プロトコルスタックに転送するように構成されている、方法。
【請求項５】
請求項１に記載の方法であって、
前記バッファは、１つのセグメントへのデータのストリーミングが終了する際に、ヘッダー情報を含むヘッダーワードを、前記セグメントのヘッダー部分に書き込むように構成されている、方法。
【請求項６】
請求項５に記載の方法であって、
前記ヘッダー情報は、前記セグメント内のワード数を特定する、方法。
【請求項７】
請求項１に記載の方法であって、
前記取得エンジンと前記バッファとの間に圧縮エンジンを備える、方法。
【請求項８】
請求項７に記載の方法であって、
前記圧縮エンジンは２段階の圧縮を実施可能であり、
第１段階は、１つのグループの最初のワードが第１のビット数を有し、それ以降のワードが、前記第１のビット数よりも少ない第２のビット数を有する差分ワードとなるように、データをグループにフォーマットすることを含む、方法。
【請求項９】
請求項８に記載の方法であって、
１つのグループの前記差分ワードは、時間差分ワードと強度差分ワードとのワード対を含む、方法。
【請求項１０】
請求項８に記載の方法であって、
第２段階の圧縮は、LZRW3型の圧縮を利用する、方法。
【請求項１１】
請求項７に記載の方法であって、
前記取得エンジンにおいて、ゼロ値を取り除く予備段階のデータ圧縮を実行する、方法。
【請求項１２】
請求項１に記載の方法であって、
前記プロトコルスタックは、ハードウェア・プロトコルスタックである、方法。
【請求項１３】
請求項１に記載の方法であって、
前記バッファと前記プロトコルスタックの機能は、ＦＰＧＡ（Field Programmable Gate Array）により実現される、方法。
【請求項１４】
請求項１３に記載の方法であって、
前記取得エンジンと前記バッファとの間に、ＦＰＧＡにより実現される圧縮エンジンを備える、方法。
【請求項１５】
請求項１に記載の方法であって、
前記コンピュータシステムは、ホストコンピュータシステムと通信を行なう内蔵型コンピュータシステムである、方法。
【請求項１６】
質量分析装置であって、
イオン源と、イオン検出器と、データ取得エンジンと、コンピュータシステムと、を備え、
前記データ取得エンジンは、前記イオン検出器からデータを受信して、前記受信したデータの強度ピークを検出して、前記検出したピークに対して前記ピークに関する時間と強度との情報を含むデータを生成して、前記時間と強度との情報を含むデータを前記コンピュータシステムに伝達し、
前記データ取得エンジンと前記コンピュータシステムとの間にデータスループット最適化モジュールが備えられて、前記取得エンジンからの前記データは前記データスループット最適化モジュールを通して送られ、
前記データスループット最適化モジュールは、受信したデータのバッファリング、フォーマット及びパケット化を行なってパケット化したデータをプロトコルスタックに送るバッファを備え、
前記プロトコルスタックは、前記パケット化したデータをネットワークインターフェースに送り、
前記ネットワークインターフェースは、前記パケット化したデータを前記コンピュータシステムに送り、
前記バッファは複数のセグメントを備え、各セグメントは、所定数のビットからなる複数の部分として構成されるメモリーブロックにより規定され、各セグメントの少なくとも１つのヘッダー部分が、前記セグメントの内容に関するヘッダー情報を含むヘッダーワード用に確保され、
各チャンクが前記セグメントの前記部分のうちの１つの部分を占めるような
前記時間と強度との情報を含むデータチャンクが、前記バッファの前記セグメントのうち最初の１つのセグメントにストリーミングされ、前記最初の１つのセグメントが充填されると、データチャンクが前記バッファの次のセグメントにストリーミングされ、前記ヘッダー情報を含む前記セグメントのうちの前記最初の１つのセグメント内のデータが前記プロトコルスタックに転送される、質量分析装置。
【請求項１７】
請求項１６に記載の質量分析装置であって、
前記バッファは、ＦＩＦＯ（First In First Out）バッファである、質量分析装置。
【請求項１８】
請求項１７に記載の質量分析装置であって、
前記バッファは、リングバッファである、質量分析装置。
【請求項１９】
請求項１６に記載の質量分析装置であって、
スキャン終了時に、前記取得エンジンにより、スキャン終了マーカーを含むスキャン終了ワードを生成し、
前記バッファは、１つのセグメントにストリーミングされたデータにスキャン終了マーカーが含まれている場合に、そのセグメントへのデータのストリーミングを終了し、以降のデータを前記バッファ内の次のセグメントにストリーミングし、前記最初のセグメント内のデータを前記最初のセグメントから前記プロトコルスタックに転送するように構成されている、質量分析装置。
【請求項２０】
請求項１６に記載の質量分析装置であって、
前記バッファは、１つのセグメントへのデータのストリーミングが終了する際に、ヘッダー情報を含むヘッダーワードを、前記セグメントのヘッダー部分に書き込むように構成されている、質量分析装置。
【請求項２１】
請求項２０に記載の質量分析装置であって、
前記ヘッダー情報は、前記セグメント内のワード数を特定する、質量分析装置。
【請求項２２】
請求項１６に記載の質量分析装置であって、
前記取得エンジンと前記バッファとの間に圧縮エンジンを備える、質量分析装置。
【請求項２３】
請求項２２に記載の質量分析装置であって、
前記圧縮エンジンは２段階の圧縮を実施可能であり、
第１段階は、１つのグループの最初のワードが第１のビット数を有し、それ以降のワードが、前記第１のビット数よりも少ない第２のビット数を有する差分ワードとなるように、データをグループにフォーマットすることを含む、質量分析装置。
【請求項２４】
請求項２３に記載の質量分析装置であって、
１つのグループの前記差分ワードは、時間差分ワードと強度差分ワードとのワード対を含む、質量分析装置。
【請求項２５】
請求項２３に記載の質量分析装置であって、
第２段階の圧縮は、LZRW3型の圧縮を利用する、質量分析装置。
【請求項２６】
請求項２２に記載の質量分析装置であって、
前記取得エンジンにおいて、ゼロ値を取り除く予備段階のデータ圧縮を実行する、質量分析装置。
【請求項２７】
請求項１６に記載の質量分析装置であって、
前記プロトコルスタックは、ハードウェア・プロトコルスタックである、質量分析装置。
【請求項２８】
請求項１６に記載の質量分析装置であって、
前記バッファと前記プロトコルスタックの機能は、ＦＰＧＡ（Field Programmable Gate Array）により実現される、質量分析装置。
【請求項２９】
請求項２８に記載の質量分析装置であって、
前記取得エンジンと前記バッファとの間に、ＦＰＧＡにより実現される圧縮エンジンを備える、質量分析装置。
【請求項３０】
請求項１６に記載の質量分析装置であって、
前記コンピュータシステムは、ホストコンピュータシステムと通信を行なう内蔵型コンピュータシステムである、質量分析装置。
【発明の詳細な説明】
【技術分野】
【０００１】
［クロスリファレンス］
本出願は、２００９年５月２９日に出願された米国仮特許出願No.US61/182,124及び２００９年５月２９日に出願された英国特許出願No.0909284.2に基づく優先権を主張するものであり、前記出願の内容は、参照することにより、その全体があらゆる目的で本明細書に組み込まれる。
【０００２】
本発明は、質量分析計の検出器信号、具体的には飛行時間型質量分析計の信号のデジタル化及び処理のための取得システムの分野に関する。
【背景技術】
【０００３】
飛行時間型質量分析計は、イオン源と、パルス加速領域と、フィールドフリー領域と、検出器、とを備える。サンプル（試料）がイオン源に導入されると、イオン源でサンプルがイオン化されて、加速領域内のパルス電場による加速が可能になる。加速されたイオンは、イオンの質量対電荷比の平方根に比例する速度で、フィールドフリー領域を通って移動する。したがって、イオンが検出器に到達する時間は、質量対電荷比に応じて決まる。フィールドフリー領域の長さを制限する実際的な制約により、優れた質量分解能を得るためには、ＧＨｚの範囲でサンプリングを行なう取得システムにより、検出器信号をデジタル化する必要がある。
【０００４】
出力信号は、時間的に２つの期間に分けられる。第１の期間は、スキャン期間であり、検出器信号がサンプルの質量スペクトルを表わす場合には、加速パルスが生じた時点で開始される。第２の期間は、各スキャンを互いに分離するためのインタースキャン期間である。
【０００５】
サンプリングされた信号は取得モジュール内で処理されてピークが検出されるが、それでも、大量のデータを、取得モジュールから、質量分析計の内蔵コンピュータシステムに、さらに、ホストコンピュータシステムに転送する必要がある。
【０００６】
内蔵コンピュータシステムは、２つの連続するスキャンの間に、すなわち、インタースキャン期間に、データを転送する必要がある「スキャンごと」基準で、取得したデータを用いる。この期間には、装置はデータを取得しないため、事実上の「デッドタイム（不感時間）」となる。このため、インタースキャン期間を最小限に抑えて、できるだけ早くデータを転送する必要がある。
【０００７】
イオン移動度分光分析法（Ion Mobility Spectrometry: IMS）等の新しい分析手法が開発されるにつれて、スキャン毎のデータ量が増大し、さらに高速の転送速度が必要になる。
【０００８】
本発明の目的は、質量分析計データ取得システムにおけるデータスループット速度を向上させることである。
【発明の概要】
【０００９】
本発明の１つの態様は、質量分析計のデータを取得する方法であって、取得エンジンが、質量分析計のイオン検出器からデータを受信し、強度ピークを検出し、検出したピークに対して、ピークに関する時間と強度との情報を含む、所定数のビットからなるデータワードを生成し、データワードに対応するデータをネットワークインターフェースを用いて、プロセッサに伝達する。取得エンジンとネットワークインターフェースとの間で、データチャンクを受信するバッファと、ネットワークインターフェースに接続されるプロトコルスタックとを備えるデータスループットモジュールを介して、データワードに対応するデータチャンクがやり取りされる。ここで、バッファは多数のセグメントを備え、各セグメントは所定数のビットからなる複数の部分として構成されるメモリーブロックにより規定され、各セグメントの少なくとも１つのヘッダー部分がセグメントの内容に関するヘッダー情報を含むヘッダーワード用に確保される。各チャンクがセグメントの部分のうちの１つの部分を占めるようなデータチャンクを１つのセグメントにストリーミングして、そのセグメントが充填されると、データを次のセグメントにストリーミングする一方で、最初のセグメント内のデータを、最初のセグメントからプロトコルスタックに転送する。
【００１０】
本発明の別の態様は、質量分析計のデータ取得装置であって、質量分析計のイオン検出器からデータを受信し、強度ピークを検出し、検出したピークに対して、ピークに関する時間と強度との情報を含む、所定数のビットからなるデータワードを生成するように構成される取得エンジンと、データワードに対応するデータをプロセッサに伝達するネットワークインターフェースと、を備える。データスループットモジュールが、取得エンジンとネットワークインターフェースとの間に備えられ、データスループットモジュールは、データワードに対応するデータチャンクを受信するバッファと、ネットワークインターフェースに接続されるプロトコルスタックと、を備える。ここで、バッファは多数のセグメントを備え、各セグメントは所定数のビットからなる複数の部分として構成されるメモリーブロックにより規定され、各セグメントの少なくとも１つのヘッダー部分がセグメントの内容に関するヘッダー情報を含むヘッダーワード用に確保される。各チャンクがセグメントの部分のうちの１つの部分を占めるようなデータチャンクを１つのセグメントにストリーミングして、そのセグメントが充填されると、データを次のセグメントにストリーミングする一方で、最初のセグメント内のデータを、最初のセグメントからプロトコルスタックに転送するように、バッファが構成される。
【００１１】
本発明の別の態様は、質量分析計のデータ取得装置であって、質量分析計のイオン検出器からデータを受信し、強度ピークを検出し、検出したピークに対して、ピークに関する時間と強度との情報を含むデータワードを生成するように構成される取得エンジンと、データワードに対応するデータをプロセッサに伝達するネットワークインターフェースと、を備える。データスループットモジュールが、取得エンジンとネットワークインターフェースとの間に備えられ、データスループットモジュールは、データワードに対応するデータチャンクを受信するリングバッファを備える。本発明の別の態様は、質量分析計のデータ取得装置であって、質量分析計のイオン検出器からデータを受信し、強度ピークを検出し、検出したピークに対して、ピークに関する時間と強度との情報を含むデータワードを生成するように構成される取得エンジンと、データワードに対応するデータをプロセッサに伝達するネットワークインターフェースと、を備える。データスループットモジュールが、取得エンジンとネットワークインターフェースとの間に備えられ、データスループットモジュールは、圧縮エンジンを備える。
【００１２】
本発明の別の態様は、質量分析計のデータ取得装置であって、質量分析計のイオン検出器からデータを受信し、強度ピークを検出し、検出したピークに対して、ピークに関する時間と強度との情報を含むデータワードを生成するように構成される取得エンジンと、データワードに対応するデータをプロセッサに伝達するネットワークインターフェースと、を備える。データスループットモジュールが、取得エンジンとネットワークインターフェースとの間に備えられ、データスループットモジュールは、プロトコルスタックを備える。本発明の別の態様は、質量分析計のデータ取得装置であって、質量分析計のイオン検出器からデータを受信し、強度ピークを検出し、検出したピークに対して、ピークに関する時間と強度との情報を含むデータワードを生成するように構成される取得エンジンと、データワードに対応するデータをプロセッサに伝達するネットワークインターフェースと、を備える。データスループットモジュールが、取得エンジンとネットワークインターフェースとの間に備えられ、データスループットモジュールは、（ｉ）圧縮モジュールとリングバッファ、又は、（ｉｉ）圧縮モジュールとプロトコルスタック、又は、（ｉｉｉ）圧縮モジュールと、リングバッファと、プロトコルスタック、又は、（ｉｖ）リングバッファとプロトコルスタックを備える。
【００１３】
本発明の別の態様は、質量分析計のデータを取得する方法であって、取得エンジンにより、質量分析計のイオン検出器からデータを受信すること、受信したデータの強度ピークを検出すること、検出したピークに対して、取得エンジンにより、ピークに関する時間と強度との情報を含むデータを生成すること、及び、時間と強度との情報を含むデータを、ネットワークインターフェースを介してプロセッサに伝達すること、を備える。取得エンジンからのデータは、受信したデータのバッファリング、フォーマット及びパケット化を行なって、パケット化したデータをプロトコルスタックに伝達するバッファを備えるデータスループット最適化モジュールに送られ、プロトコルスタックは、データをネットワークインターフェースに伝達する。
【００１４】
添付の図面を参照して、以下に説明する好適な実施形態を検討することにより、本発明をよりよく理解することができるであろう。
【図面の簡単な説明】
【００１５】
【図１】本発明における飛行時間型質量分析システムを示す概略図。
【図２】図１の質量分析計の取得システムに含まれるデータスループット最適化モジュールを示すブロック図。
【図３ａ】データスループット最適化モジュールに含まれるリングバッファの動作を示す概略図。
【図３ｂ】データスループット最適化モジュールに含まれるリングバッファの動作を示す概略図。
【図３ｃ】データスループット最適化モジュールに含まれるリングバッファの動作を示す概略図。
【図４ａ】プロトコルスタックに出力されるリングバッファ・セグメントのフォーマットを示す図。
【図４ｂ】プロトコルスタックに出力されるリングバッファ・セグメントのフォーマットを示す図。
【発明を実施するための形態】
【００１６】
本発明の実施形態において、バッファは、質量分析計からのデータのバッファリング、パケット化及びフォーマットを実行する。バッファによるデータのフォーマットは、プロトコルスタックに対応して、システムのデータスループットを最大にするように、最適化される。プロトコルスタックは、ネットワークリンクを介した内蔵コンピュータへのデータ転送を行なう。好適な実施形態において、プロトコルスタックは、性能を最適化したハードウェア・スタックである。
【００１７】
好適な実施形態において、データ取得エンジンは、強度ピークを検出し、各ピークに対して、ピーク上の多数の点に関する時間と強度との情報を含む、所定数のビットからなる多くのデータワードを生成する。
【００１８】
代表的な用途において、ワードは、例えば、６４ビットの長さのものでもよいが、所定数のビットは、データ要件に応じて、この値よりも大きくても小さくてもよい。バッファは多数のセグメントを備え、各セグメントは、多数の６４ビット部分から構成される。たとえば、２０４８個の部分から構成される場合には、各部分は６４ビットを受信可能であり、各セグメントは１６キロバイトのメモリを占有する。このようなセグメントを、たとえば、８個以上備える。
【００１９】
バッファに送られるデータチャンクは、元々の６４ビットワードでなくてもよく、以下で詳述するように、データ取得エンジンとバッファとの間で圧縮エンジンを用いる場合には、たとえば、ワードを表わすデータチャンクでもよい。
【００２０】
各セグメントが、スキャン情報等のヘッダー情報用に１つ以上のワードを備えるようにしてもよい。好適な実施形態において、セグメント内のデータを含む多数の部分、又は、取得エンジンからのデータワードに対応するチャンクを含む多数の部分が、ヘッダー情報に格納される。セグメントには、通常、データがいっぱいまで充填されるが、状況によっては、あるセグメントが特定スキャンからのデータのうち最後のデータワードを受信することになる。この場合には、取得エンジンからの最後のデータワードに、スキャン終了マーカーが含まれる。スキャン終了マーカーが検出されると、バッファは、最初のセグメントをいっぱいまで充填することなく、次のセグメントに処理を移す。スキャン終了ワードを、最初のセグメントに書き込むようにしてもよい。そのセグメントのヘッダーワードは、そのセグメント内に含まれる部分の総数を特定する情報を備える。この場合、絶対総数でもよいし、スキャンデータワードに対応する部分の総数でもよい。いずれにしても、バッファとプロトコルスタックとの間の関係は、所定のセグメントに関してバッファからどのデータを読み出すべきかをプロトコルスタックが識別する、というものである。ネットワークを介してプロセッサに次に伝達されるデータは、バッファによる生成データでもよい、すなわち、プロトコルスタック内で１つ又は複数のヘッダーワードを取り除いたものでもよい。あるいは、ヘッダーワードを保持したものでもよい。
【００２１】
バッファは、ＦＩＦＯ（First In First Out）バッファでもよく、好適なバッファはリングバッファである。このようなバッファでは、バッファが充填されると、バッファ内の最も古いデータ上に新しいデータが上書きされる。このような上書きを防ぐために、本発明の好適な実施形態では、バッファからのデータ出力速度がバッファ内へのデータフロー速度に匹敵するほど十分に速くない場合には、取得エンジンからのデータの受信速度を制御する。
【００２２】
本発明の一部の実施形態において、取得エンジンとリングバッファとの間に、所定のネットワーク配線速度に対してデータのスループットを増大させるデータ圧縮エンジンを備えるようにしてもよい。データ圧縮エンジンは、LZRW3のような可逆データ圧縮（ロスレス圧縮）手法を用いる。データ圧縮エンジンは、たとえば、取得エンジンから、８バイト列として６４ビットのワードを受信し、受信したワードから、８バイト以下の圧縮データ列からなるデータチャンクを生成するものでもよい。データ圧縮エンジンは、複数段階で動作するものでもよい。たとえば、２段階システムでは、LZRW3圧縮の前の最初の段階で、時間及び強度について、最初の６４ビットのワード値と、それ以降の差分８ビット値とで構成されるグループにフォーマットし、その差分が８ビットに収容可能なものよりも大きくなるまで、データをグループにフォーマットするようにしてもよい。さらに、ゼロ値を取り除くことが可能なレベルのデータ圧縮をＡＤＣ取得エンジンで行なうようにしてもよい。
【００２３】
バッファとプロトコルスタックの機能、及び、必要に応じて設けられる圧縮エンジンの機能を、ＦＰＧＡ（Field Programmable Gate Away）により実現するようにしてもよい。
【００２４】
以下、図面を参照して詳細に説明する。図１に示す飛行時間型質量分析システムは、イオン源１と、加速領域２と、フィールドフリー領域３と、リフレクトロン（イオンミラー）４と、検出器５と、取得システム６と、内蔵コンピュータシステム７と、ホストコンピュータシステム８と、を備える。
【００２５】
イオン源でサンプル化合物（試料化合物）から形成されたイオンは、加速領域に入り、加速電圧パルスによって加速領域からフィールドフリー領域に移動される。イオンは、加速パルスと質量によって与えられるエネルギーにより決まる速度に加速される。この場合、質量が軽いイオンほど高速になる。
【００２６】
リフレクトロンを用いて、分析計筺体の長さが一定であるのに対して、加速領域から検出器までのイオンが移動する経路の長さを増大させる。これにより、異なる速度のイオンを、より時間的に離して分離可能である。
【００２７】
イオンの速度と移動距離とによって決まる時間の後、イオンは検出器に到達し、ここで、イオンの質量を決定することができる。
【００２８】
取得システムは、検出器の出力をサンプリングした後、内蔵コンピュータシステムに送られる質量スペクトルを形成する各イオン到達時間に応じた値を生成する。このような取得システムの動作の詳細に関しては、後述する。
【００２９】
内蔵コンピュータシステムは、さらなる解析と格納を行なうために、質量スペクトルデータをホストコンピュータシステムに送る。データに応じた取得を行なえるように、内蔵コンピュータシステムでもデータを解析するようにしてもよい。これにより、質量スペクトルデータの内容を用いて、質量分析計の構成をスキャン毎に変更することができる。
【００３０】
図２に、取得システムのブロック図を示す。取得システムは、取得エンジン９と、データスループット最適化モジュール１０と、データを内蔵コンピュータシステム７に出力するためのイーサネット（Ethernet（登録商標））インターフェース１１と、を備える。データスループット最適化ブロックは、データ圧縮エンジン１２と、リングバッファ１３と、ハードウェア・プロトコルスタック１４と、を備える。
【００３１】
取得システムに入力される質量分析計からの検出信号は、取得エンジン内部で、高速アナログ・デジタル変換器（ＡＤＣ）によりサンプリングされる。次に、取得エンジンは、信号内にピークが存在する場合には、ピークを検出して、検出したピークを時間情報と強度情報からなるデータ対に変換する。ＡＤＣは、必用に応じて、ゼロ値を取り除くことにより初期段階のデータ圧縮を行なうようにしてもよい。
【００３２】
各ピークのデータ対を６４ビットのワードにフォーマットして、データスループット最適化モジュールに入力する。スキャン終了時には、いかなるピーク情報も含むことなく、スキャン完了フラグを含む特別な６４ビットワードを生成する。
【００３３】
最初の段階のデータ圧縮では、データは、１つの６４ビットワードとそれに続く複数の８ビットの差分ワードとからなるグループに変換される。この構成は、データが互いに大きく異ならない値のグループに分けられる場合に適している。１つのグループの最初の値に対して、最初の６４ビットワードを形成し、以降の値に対して、８ビットの差分ワードを形成する。１つの８ビットワードで時間差分を、また、１つの８ビットワードで強度差分を表わす。差分が８ビットで収容可能な容量を越えると、次のグループが開始され、６４ビットワードが形成される。
【００３４】
具体的なフォーマットはさまざまに変更可能である。たとえば、最初の値は、６４ビットよりも大きな容量のワードでもよいし、６４ビットよりも小さな容量のワードでもよい。また、差分ワードは、そのグループの最初のワードの容量よりも小さければ、８ビットよりも大きな容量でもよいし、８ビットよりも小さな容量でもよい。
【００３５】
最適化ブロックの次の段階は、データ圧縮エンジン１２であり、LZRW3（Lempel-Ziv Ross Williams）圧縮アルゴリズムを用いて、可逆データ圧縮（ロスレス圧縮）を行なう。LZRW3アルゴリズムは、ＦＰＧＡロジック内で非常に効率よく構築され、毎秒１ギガビットを越える非常に高いデータスループット速度で動作可能な圧縮解を与えるため、LZRW3アルゴリズムが用いられる。ただし、他のデータ圧縮アルゴリズムを用いるようにしてもよい。圧縮エンジンは、データ取得エンジンからの各６４ビットワードデータを８バイト列として処理する。ただし、LZRW3エンジンは、すべての受信データを８ビットワードとして取り扱い、より高次のフォーマットとは無関係、すなわち、８バイトで６４ビットワードが形成されているかどうかには関係が無い。圧縮エンジンからの出力はチャンクを備え、各チャンクは元のワードに対応するバイト列を含むが、圧縮時には、チャンク内に含まれるバイト数が少なくなる。
【００３６】
データ圧縮エンジンの出力は、リングバッファ１３に入力される。リングバッファの入力部は、たとえば、複数の６４ビット部分からなる１６３８４バイトのＦＩＦＯ（First In First Out）メモリのように設計される。こうすると、８個のセグメントからなるリングバッファとなり、各セグメントは、２０４８×６４ビット部分として構成される１６キロバイトのメモリブロックである。LZRW3エンジンを、一度に１６キロバイトのデータブロックで動作させて、１つのセグメントの大きさに一致させるようにしてもよい。
【００３７】
図３は、リングバッファの動作状態において、アクティブなヘッドセグメント及びテールセグメントを示す。図３ａは空の状態、図３ｂは部分的に充填された状態、図３ｃは完全に充填された状態を示す。
【００３８】
各セグメントの最初の２つの部分は、ヘッダー情報データ用に確保された部分である。データ圧縮エンジンからの受信データチャンクを、各セグメントの３番目の部分から以降を、１つのセグメントが充填されるまで、リングバッファにストリーミングする。あるセグメントが充填されると、リングバッファのヘッドポインターをリング内の次のセグメントに進める。
【００３９】
１回のスキャンにおけるすべてのデータを内蔵コンピュータシステムに送信するために、あるデータワード内でスキャン終了フラグが検出された場合も、リングバッファのヘッドポインターを次のセグメントに進める。データ取得エンジンからのデータストリーム内でスキャン終了マーカーが検出されると、検出されたスキャン終了マーカーをリングバッファ内の次の６４ビット位置に書き込む。セグメントのヘッダーにはワード数が記録されているため、内蔵コンピュータシステム及びホストコンピュータシステムは、圧縮データと、スキャンセグメントの終わりのスキャン終了マーカーとを識別できる。
【００４０】
リングバッファ１３が充填されると同時に、ハードウェアプロトコルスタック１４はこれを空にして、リングに沿ってテールセグメントを進める。リングバッファが充填されて、ヘッドセグメントがテールセグメントに追いつくと、データ圧縮エンジン１２と取得エンジン９からのデータフローを抑制する。取得エンジンがデータのストリーミングを中止すると、テールセグメントがヘッドセグメントに追いつくまで、リングバッファを空にし続ける。
【００４１】
リングバッファ内の１つのセグメントが充填されると、リングバッファは、セグメントのネットワークを介した送信が可能であることと、送信するべきワード数と、をハードウェア・プロトコルスタックに報知する。また、リングバッファは、セグメントの始まりの２つの６４ビットのヘッダー部分に、セグメント内のワード／チャンク数とスキャン関連情報とを書き込む。図４ａに完全に充填されたリングバッファセグメント１５のフォーマットを、また、図４ｂにスキャン終了時のリングバッファセグメント１６のフォーマットを示す。
【００４２】
ハードウェア・プロトコルスタックが１つのセグメントの処理を完了して、リングバッファに完了を通知すると、リングバッファは、ヘッドセグメントに向かって、テールセグメントを１つ進める。リングバッファに書き込まれるデータがなくなると、リングバッファが空にされて、テールセグメントが最終的にヘッドセグメントに追いつく。
【００４３】
リングバッファは、プロトコルスタックにより最適な伝達速度が得られるようにデータをフォーマットして、最大可能な大きさのネットワークパケットを生成する。この機能がなければ、多くの小さなネットワークパケットが生成されることになるが、各ネットワークパケットには、様々なレベルのプロトコルヘッダー・オーバーヘッドが関与するため、ネットワークの性能に大きな影響を与えることになる。
【００４４】
ハードウェア・プロトコルスタックは、各セグメントの中身を受信すると、メディアアクセス制御（Media Access Control：ＭＡＣ）とイーサネット（登録商標）インターフェースの物理層（ＰＨＹ）インターフェースとを介して、ＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）を用いてセグメントデータを送信するすべての送信動作を行なう。プロトコルスタックは、自律的に、データの受信確認を行ない、タイマーを動かして、さらに、必要に応じてデータを再送信する。
【００４５】
ハードウェア・プロトコルスタックを用いて、イーサネットインターフェース１１を介して毎秒１ギガビットという全配線速度でデータを送信することができる。
【００４６】
この実施形態において、内蔵コンピュータシステムで復元を行なって、データ取得エンジンから内蔵コンピュータに対して、イーサネット（登録商標）リンクの１ギガビット／秒よりも高速のデータスループットを実現する。最大性能を実現するために、ハードディスクへのアクセスがシステム内のボトルネックになる可能性がある場合には、内蔵コンピュータは、圧縮データを受信すると、ホストコンピュータに受信したデータを送信して、ホストコンピュータがハードディスクに圧縮データを格納するようにしてもよい。圧縮データを後で復元して、「オンザフライ」復元を実行する必要性を低減するようにしてもよい。ただし、このアプローチには、データに応じた取得ができないという問題がある。
【００４７】
データ圧縮ブロックは必須ではなく、省略してもよい。また、今後開発されるより効率的なアルゴリズム等、さまざまなアルゴリズムに応じた変更を施すようにしてもよい。
【００４８】
最適化ブロック内でデータをさらにバッファリングする必要があれば、リングバッファ内のセグメントの数を増やしてもよい。
【００４９】
より高精度な取得エンジンの開発に伴って、リングバッファのビット幅を増大させるようにしてもよい。
【００５０】
ハードウェア・プロトコルスタックの代わりに、ＦＰＧＡ内の内蔵プロセッサ上で実行されるソフトウェア・スタックを用いるようにしてもよい。このソフトウェア・スタックは、ＦＰＧＡのリソース占有率は低いものの、性能も低い。この場合でも、リングバッファは、データスループットを最適化することが可能である。
【００５１】
プロトコルスタックは、より高速のデータスループットを可能にするＵＤＰ（User Datagram Protocol：ユーザーデータグラムプロトコル）等、異なるプロトコルを実現するものでもよい。ＵＤＰではデータ配信が保証されていないため、単純なポイントツーポイント・ネットワークでのみ用いられる場合が多いが、単純な形態のハンドシェーキングによりデータ伝達の信頼性を向上させるようにしてもよい。また、ＲＵＤＰ（Reliable User Datagram Protocol）等のプロトコルを用いて、ＵＤＰとＴＣＰとの中間の形態としてもよい。
【００５２】
ＡＳＩＣ（Application Specific Integraed Circuit：特定用途向け集積回路）等、他の構成が可能なデジタル電子機器内で最適化手法を実施するようにしてもよい。
【００５３】
一般に、データスループット最適化モジュール１０の３つの構成部、すなわち、圧縮エンジン１２、リングバッファ１３及びプロトコルスタック１４の各々を、個別に用いてもよいし、あるいは、任意の所望の組み合わせで用いることもできる。
【００５４】
本発明の実施形態は、質量分析計からデータを取得して、コンピュータシステムにそのデータを伝達するシステム及び方法を提供する。システムは、データ取得エンジンと、ネットワークインターフェースと、リングバッファ及びプロトコルスタックを有するスループット最適化モジュールと、を備える。圧縮エンジンを取得エンジンとリングバッファとの間に備えるようにしてしてもよい。リングバッファは、取得エンジンからのデータワードの大きさに各々適合するメモリー部分を含む多数のセグメントとして構成される。１つのセグメントが、ワードに対応するデータで完全に充填されるか、又は、部分的にデータが充填された状態でスキャン終了マーカーを含むデータを受信すると、このセグメントへのデータのストリーミングを終了し、このセグメント内のワード数をこのセグメントのヘッダーワードに書き込み、このセグメント内のデータをプロトコルスタックに移動させる。以降のデータは、バッファ内の次のセグメントが受信する。
【００５５】
以上、本発明をその好適な実施形態を参照して詳述したが、当業者には自明のことであるが、特許請求の範囲に記載される本発明の要旨を逸脱しない範囲において、形態や詳細において、種々の変形や変更が可能である。
【図１】
0005103556.tif 000002
【図２】
0005103556.tif 000003
【図３ａ】
0005103556.tif 000004
【図３ｂ】
0005103556.tif 000005
【図３ｃ】
0005103556.tif 000006
【図４ａ】
0005103556.tif 000007
【図４ｂ】
0005103556.tif 000008