LabVIEWによる設計とテストの統合
概要
内容
従来の開発手法が抱える問題点
一般に、設計プロセスのさまざまな工程で利用できることをうたうツールは、各工程のすべての作業にわたって利用可能な統一的な環境/言語を用意するというアプローチをとっているわけではありません。そうではなく、各工程/各作業間の障壁を軽減することによって目的を達成しようとしています。ここで、新たなRF通信規格を使用するシステムを開発するケースについて考えてみます。その場合、通信システムの開発を専門とする技術者は、純粋にアルゴリズム的/数学的な意味で信号ストリームをモデル化してシミュレーションを行うでしょう。そのモデルのテストを担当者が行う際には、多くの場合、独自のテストベンチを作成することになります。また、業界標準のプロトコルに対応する場合に限れば、その規格に対する適合性をチェックするためのテストスイートを利用することも可能です。
設計の工程で、必要となる機能を正確に実現できたら実装の工程へと移行します。その際、従来は、別のチームにアルゴリズムを引き渡し、そのチームが、アルゴリズムの内容をANSI CやHDL（ハードウェア記述言語）のコードに手作業で書き直す（実装に変換する）という手法が用いられてきました。
図1. Vダイアグラムは、設計から、実装、テストまでの理想的な流れを表現している。V字で表される全工程を通じて共通のシステム開発言語を使用することにより、知識とアルゴリズムの再利用性を最大化することができる。同時に、変換作業、バグの発見/修正作業で生じるミスを最小限に抑えることが可能になる。
アルゴリズムだけでなく、テストベンチを変換する作業が必要になることもあります。その変換作業には、異なるスキルを持つ別のチームが必要となります。また、変換作業において何らかのミスや不具合があると、新たなバグの発生やテストカバレッジの低下といった問題が生じることになります。その結果、実装段階でバグが検出されて、設計工程への手戻りが発生するといった事態に陥ります。加えて、アルゴリズムと実装との間に差異が存在することで、バグの発見/修正に長い時間を要するというケースもあります。
このような問題を軽減するために、多くのツールは、シミュレーション用のプログラムを基にANSI C/HDLのコードを自動生成（変換）する機能を備えています。この機能によって、プロセッサやFPGAにコードをデプロイ（配備）する段階に移行するまでの時間を大幅に削減することができます。ただし、その結果、ANSI CやHDLについて熟知した技術者による配備作業や最終的なデバッグ作業が不要になるというわけではありません。最初に行った設計が完璧である可能性が低いのと同様に、自動生成したコードも完璧である可能性は低いからです。
全工程で使用する単一のツールとしてLabVIEWを導入
上述した問題を解決するのが、ナショナルインスツルメンツ（NI）のシステム開発ソフトウェアであるLabVIEWです。通信システムの設計の例で言うと、設計者は、テストベンチを実装する前に、LabVIEWを使用して通信ストリームのモデル化を行うことができます。設計とテストの要件を満たしたら、システム開発者は、設計アルゴリズムの実装先としてプロセッサとFPGAのうちどちらかを選択するよう設定するだけで済みます。このようにして、実験的な意味も含まれる初期の設計から最終的な実装までの全工程において、単一の環境、アルゴリズム、デバッグ方法、テスト方法を使い続けることができます。その結果、知識とアルゴリズムの再利用性を最大化することができるとともに、変換作業やバグの発見/修正作業で生じるミスを最小限に抑えることが可能になります。
上述したとおり、設計、実装、テストの各工程で個々にコードを記述するのではなく、単一のアルゴリズムを再利用することによって、大きなメリットを得ることができます。では、なぜ、アルゴリズムを直接的に再利用するアプローチを採用したシステム開発ソフトウェアはほとんど存在しないのでしょうか。その答えは、「慣習によるところが大きい」ということのようです。システム開発ソフトウェアの大半は、もともとはシステムの動作を時間領域で評価するために最適化されたシミュレーションツールでした。一方、LabVIEWはもともとシステムの実装用に開発されたソフトウェアです。それが現在では、設計とシミュレーションにも対応するツールへと進化を遂げました。LabVIEWの言語、環境、そして最も重要なIP（Intellectual Property）/アルゴリズムのブロックは、プロセッサとFPGAのいずれを使用する場合でも、非常に短い時間でコンパイル/実行できるように設計されています。
LabVIEWが備える実装機能 は、アルゴリズムの再利用を可能にするだけでなく、シミュレーションで費やされる時間を大幅に短縮することができます。例えば、LabVIEWを用いると、PCで開発したアルゴリズムを、各種プロセッサに固有のマシンコードに完全にコンパイルすることができます。連続時間領域で行うシミュレーションと比較すると、純粋なデジタル信号処理（以下、DSP）の場合、アルゴリズムの実装とデバッグを非常に短い時間で完了させることができます。このメリットは、FPGAを使うことを前提とした設計を行い、それに対するシミュレーションを実施する場合と比べると、より大きなものとなります。LabVIEWはビット精度/サイクル精度のシミュレーションにも十分に対応可能ですが、機能テストがしっかりと行われるなら、多くの場合、LabVIEWは桁違いの高速化を達成します。なぜなら、機能を実現するコードが完全にコンパイルされ、ローカルでの実行に向けて最適化されるからです。実装で用いる低速なシミュレーションアルゴリズムよりも、シミュレーションで用いる高速な実装アルゴリズムを再利用するほうがより実用的です。これこそが、ほかのシステム開発ソフトウェアにはない、LabVIEWの大きなメリットです。
RFシステム開発におけるLabVIEWのメリット
RFシステムの開発における設計とテストの統合に話を戻しましょう。通信システムの開発には、設計とテストの統合において、独特の複雑さが加わります。最も重要なのは、RFレシーバをテストする際にはトランスミッタを用意する必要があり、トランスミッタをテストするにはレシーバを用意する必要があるという点です。一般に、テスタの信号生成/信号計測の性能は、設計で扱う信号や計測の特性を上回るものでなければなりません。また、RFによる通信手法や規格は非常に短期間で変更されるため、テスタにも柔軟性と変化への素早い対応能力が要求されます。従って、RF分野で用いる試験装置は、理想的には、送信/受信に用いるDSPアルゴリズムを素早く再利用できることに加え、非常に優れた性能と柔軟性を備えているものでなければならないということになります。従来は、そのようなテスタを実現するために、特定の通信カテゴリでの計測/テスト専用のものとして、固定機能の計測器が開発されていました。
設計とテストを真の意味で統合するには、テストのプロセスとテストベンチ、それらに付随する要件を設計フローに取り込まなければなりません。また、設計とテストは、シミュレーションではなく、実世界のハードウェアと実世界の信号を使用して直接実行するのが理想的です。LabVIEWとベクトル信号トランシーバのNI PXIe-5644Rを使用すれば、そのような理想的な状態を得ることができます。その場合、通信ストリームに対するデジタル信号処理を担うビルディングブロックを定義し、PC上で期待どおりの機能が実行できることが確認できたら、設計者はPC上の設計環境から、ベクトル信号トランシーバ上で実行されるFPGAへと、アルゴリズムの実装場所を設定し直すことができます。
図2. ベクトル信号トランシーバであるNI PXIe-5644Rのアーキテクチャを示している。このアーキテクチャにより、ユーザが修正可能なDSPブロックを、ホストと、デバイスのファームウェアのいずれにもデプロイ（配備）してシミュレーションを実行することができる。ほかの入出力（I/O）やメモリインタフェースを使って、アルゴリズムの設計を補完するよう修正を施すことも可能になる。
上述した移行を実施する際の主要な要素であり、アルゴリズムの設計から最終的なデプロイメント（配備）（設計の検証のための配備、テストのための配備を含む）への移行において発生しがちな障害は、実世界の時間との適切な統合です。そして、さらに重要なのが、ハードウェアI/Oと信号のキャリブレーション（校正）です。従来の設計/テスト手法では、DSPアルゴリズムの設計と、デバイス用のファームウェアの実装（I/Oの統合を含む）は異なるチームによって行われていました。NIは、ベクトル信号トランシーバ、LabVIEW、プログラマブルなデバイスであるRIO（再構成が可能なI/O）に加え、再プログラミングが可能で、非常に柔軟性が高く、高度に最適化されたIPブロックを備えるRFハードウェアプラットフォームを提供しています。そのIPブロックを使用すれば、信号のキャリブレーション機能を含めて高速A/Dコンバータや高速D/Aコンバータを統合する際や、ホストプロセッサ/高速オンボードメモリへのDMA（Direct Memory Access）データストリームを統合する際の複雑さを軽減することができます。また、ベクトル信号トランシーバに含まれるIPには、非常に重要な特性が3つあります。1つは、PC上で機能的なシミュレーションを実行可能なので、アルゴリズムの設計を行う際に利用できるということです。2つ目は、必要に応じて、ソースコードを参照したり、修正したりすることができる点です。そして3つ目は、前述したとおり、実際のリアルタイム実行へとスムーズに移行できることです。
設計、テスト、デプロイメント（配備）の統合
アルゴリズムの設計からデプロイメント（配備）まで、真の意味で一貫したシステム開発のフローを実現するには、ソフトウェアとハードウェアについて包括的な見識を持つことが必要です。適切なタイミング機能、I/O、DSPアルゴリズムのIPを備えるソフトウェアを選択してください。そのDSPアルゴリズムのIPは、シミュレーション時間での実行が可能なだけでなく、機能のデバッグについても、即座に設計に戻れるよう迅速に実行できるものでなければなりません。また、最終的には、設計とテストの両方のコードを、PC環境から、実装先となる再プログラミングが可能なハードウェアへと移行する必要があります。
設計したアルゴリズムと開発したテストのコードは重要なIPです。多くのシステム開発ツールの目的は、あらゆる場面で同じIPを再利用できるようにし、開発の初期段階で行う設計と最終的な実装の差を最小限に抑え、生産性を最大化することです。ただし、これを実現可能なシステム開発ソフトウェアは、次のようないくつかの特徴を持つものに限られます。すなわち、対話形式で進める設計プロセスに向けて開発されており、再構成可能なハードウェアと完全に適合し、オープンかつ再利用が可能なビルディングブロックを備え、もともと実装に向けて開発されたものである、ということです。これらの特徴を備えるのが、ほかならぬLabVIEWです。LabVIEWとRIOに対応したベクトル信号トランシーバとを組み合わせることにより、本稿で説明した課題の解決が可能になるのです。