機能的プロトタイプを作成する7つのステップ

機能的プロトタイプとは、最終製品のハードウェアやソフトウェアと同様に動作する、あるいはその動作をシミュレーションする、インタラクティブでテスト可能な製品モデルのことを指します。機能的プロトタイプをテストすることで、設計者とエンジニアは生産前に問題を特定できるため、製造中またはリリース後に発生する問題の解決に費やす時間とコストを節約することができます。

ペーパーデザインの重要性

新しいデバイスについて革新的で刺激的なアイデアが浮かんだら、ペーパーデザインは省略して、すぐに物理プロトタイプの試作を始めたいという思うかもしれません。この誘惑に打ち克つことで、長期的に見たときに、時間を節約し、無駄な労力をしないことが可能になります。ペーパーデザインに時間を投資することで、後で大きな配当を生み出し、かつ設計プロセスにおける多くの一般的な落とし穴を避けることができます。ペーパーデザインとは、プロトタイプの詳細な設計をペンまたは鉛筆で紙に書き出すという意味ではありません。それは、ソフトウェアコーディングやハードウェア設計を行う前に計画を立てることを指します。 ペーパーデザインの利点には、頭の中にあるアイデアを紙に書き出すことで、開発が進んでからではなく、早い段階でミスを発見したり、早期に導入したお客様からのフィードバックを得られることなどがあります。

自分の要件を定義

素晴らしいアイデアとナプキンの裏側に書いたスケッチから詳細なペーパーデザインにどのように進めばよいでしょうか。最初のステップは、ユーザ要件のリストを作成して自分の目標を明確に定義することです。これらの要件は可能な限り具体的に定義する必要があります。ここで定義した要件を確実に満たすために、この段階で調査することが重要です。その設計は実現可能ですか。あなたの要件を満たすことが現実的にできますか。設計に関するニーズと希望を区別してください。イノベータとして、高度だが、必要ではない機能をプロトタイプに追加したいと思うかもしれませんが、目的に照らして、それらに忠実に従ってください。

要件からコンポーネントを抽象化する

抽象化することで、アプリケーションの作成方法を定義せずにアプリケーションを記述することができます。抽象化は、アプリケーションを高い概念レベルに一般化することです。抽象化には、手続きの抽象化とデータの抽象化があります。手続きの抽象化は、手続きの機能を手続きの実装方法から分離することです。データの抽象化は、保存するデータをデータを保存する物理的な方法から分離することです。抽象化を支援するには、システム要件書からキーとなる動詞と名詞を削除します。これらの動詞と名詞から、プログラムの目的とユーザインタフェースの一部となるオブジェクトを識別することができます。動詞と名詞は、プロトタイプを完成させるために必要なハードウェアコンポーネントを識別するのにも役立ちます。

フローチャート

デバイス要件から抽象化されたコンポーネントのセットを取得したら、フローチャートを使用して、抽象化されたコンポーネントからソフトウェアデザインに移行することができます。フローチャートのためにアプリケーションをより管理しやすい単位に分割することは、アプリケーションフローの理解を深めることができます。LabVIEWは、エンジニアや科学者の生産性を高めることを目的に設計されたグラフィカルプログラミング開発環境であり、ペーパーデザインをコードにすばやく変換するのに理想的なツールです。LabVIEWブロックダイアグラムはフローチャートに似ているため、フローチャートからソフトウェアコードへの移行が簡単に行えます。

^{図1: 血圧モニタのフローチャート、状態図、ステートマシン。状態図で定義された5つの状態がステートマシンに実装されていることに注目}

状態図

状態図は、プログラムの状態と遷移を示す特殊タイプのフローチャートです。各状態は、条件を満たすか、動作を実行するか、イベントを待機します。状態を遷移させるのは、プログラムを次の状態に移行させる条件、動作、またはイベントです。状態アーキテクチャは、ほとんどの組込システムで使用されており、状態図はそのプロトタイプを作成するのに役立ちます。プロトタイプはアイドル状態であっても常に所定の状態にあるという前提で設計されているからです。

LabVIEWでは、ステートマシンは、ケースストラクチャ、Whileループ、シフトレジスタで構成されます。初期ケースはループの外側で指定します。状態図の各状態は、ケースストラクチャの1つのケースに対応します。各ケースには、1つの状態を実装するコードと、他のケースへの遷移を定義するロジックが含まれています。このアーキテクチャを使用すると、ステートマシンにケースとロジックを追加することで、アプリケーションを拡張することができます。

多くの場合、ユーザインタフェース(UI)のプロトタイプ作成は、ペーパーデザインをソフトウェアに移行するときに行うのが最適です。この移行時にUIのプロトタイプを作成することは、設計アーキテクチャとアプリケーション要件を検討するのに役立ちます。また、潜在的な顧客や投資家に向けて具体的なデバイス機能をデモするために使用できることも重要な利点です。プロトタイプが複雑になればなるほど、設計への支持を集めたり、フィードバックを収集したりするためにUIプロトタイプの価値が高まります。最後に、プロトタイプ設計者が機能の設計や追加をアピールする際に大きな役割を果たすことができます。これらのUIプロトタイプの利点は、コストを抑え、開発時間を短縮し、最終的にはより良い製品を生み出すことにつながります。

^{図2: LabVIEWで設計したUI (コードはUI Interest Groupから取得可能)}

LabVIEWにはフロントパネルが内蔵されているため、カスタマイズ性の高いUIをすばやく開発するのに最適です。LabVIEWでは、設計とプロトタイプのサイクルを繰り返す際に機能を簡単に追加できるため、サイクル中の設計変更にかかる労力を最小限に抑えることができます。LabVIEWを使用すれば、UIのプロトタイプをすばやく作成し、試作プロセスの中で変更し、最終製品としてデプロイすることができます。

モックアップの作成

LabVIEWでは、コードを書き始めたり、アプリケーションアーキテクチャを完成させたりする前に、必要なすべての入力と出力を備えたフロントパネルを設計することができます。このUIモックアップは、必要な入力と出力を決定するのに役立ちます。また、これをもとに要件を絞り込むことができます。

^{図3: LabVIEWで作成したUIモックアップ}

機能の追加

UIプロトタイプを作成した次のステップは、ユーザがフロントパネルを操作したり、メニューをクリックしたり、制御器を調整したり、サンプルデータセットや乱数生成に基づいて結果を表示できるように機能を追加することです。このアプローチの美しさは、UIのプロトタイプを作成していると同時にソフトウェア設計構造を定義していることです。両方がうまく完了すれば、残りの試作プロセスでストラクチャを構築することができます。

仮想プロトタイピングとは、機械的なモデリングとシミュレーションを制御系設計と組み合わせて、組込制御システム/デバイスの設計と試作の効率を高める画期的な手法です。仮想プロトタイピングを使用すると、ソフトウェア設計/制御アルゴリズムを3D CADメカニカルモデルに接続して、物理プロトタイプを作成する前にシステムの機械構造をテストすることができます。

^{図4: 仮想プロトタイピングの手法}

仮想プロトタイピングの必要性

仮想プロトタイピングを作成することで、お客様の要件を正しく理解し、設計プロセスのスピードが上がり、効率的にデバッグを行うことができるため、機械設計に関するリスクを軽減することができます。仮想プロトタイプを作成しない場合、お客様から製品の動作に関する具体的なのフィードバックを受け取るためには、完成した物理プロトタイプを作成する必要があります。仮想プロトタイピングを使用すれば、実際の機械を作成する前に、機械構造をデジタル形式で表したものをお客様に見せて、フィードバックを得ることができます。これにより、お客様も設計プロセスに深く関わることができ、設計者は手遅れになる前の試作プロセスの早い段階で設計を改善することが可能になります。

また、仮想プロトタイプを作成することで、製品の市場投入までの時間を短縮することができます。この手法では、仮想設計を概念化し、設計を繰り返す行うことができるため、物理プロトタイプの段階では最初から完成度の高いものを作成することができます。制御ソフトウェアを3D CADモデルに接続することができるため、これまでは物理プロトタイプを作成するまで見つけられなかったような問題を発見して、修正することが可能です。2D/3Dモーションプロファイルなどのモーションコントロールコードを作成して、3Dモデルでコードを実行することができます。部品が大きすぎて衝突が起きる場合や、輪郭モーションと線形モーションの違いを確認したい場合も、仮想プロトタイピングの段階で問題を修正し、確認することができます。仮想プロトタイピングでは、従来の設計方式に比べ、早い段階で重要な設計上の判断を下すことが可能です。

NIによる仮想プロトタイピングのメリット

LabVIEWを使用して、あらゆる機械システムをシミュレーションできます。LabVIEW Control Design and Simulation Moduleを使用すると、開ループモデルの動作解析、閉ループコントローラの設計、オンライン/オフラインでのシステムシミュレーション、物理的な実装を行うことができます。

^{図5:LabVIEW Control Design and Simulation Tools}

伝達関数、状態空間、または極/ゼロ点/ゲインを使用して、モデルを第一原理から作成することができます。また、時間ステップ応答やボード線図などの時間/周波数解析ツールを使用して、そのようなモデルの開/閉ループの動作を対話的に解析することもできます。MIMO (multiple input, multiple output) システムとSISO (single input, single output) システムの両方に対応した内蔵ツールを使用し、シミュレーション機能を活用して線形/非線形システムのダイナミクスを検証します。内蔵ツールを使用して、The MathWorks, Inc.Simulink®ソフトウェアで開発したモデルをLabVIEWで動作するように変換することもできます。

真に機能的なシステムを作成するには、プロトタイプに I/O を追加することが不可欠です。センサ入力と制御出力を追加することで、その設計が機能し、現実世界で実装可能であることを証明できます。ペーパーデザインを作成し、その設計図をソフトウェアに組み込み、仮想環境でシミュレーションしても、大部分はまだ概念的な作業でしかありません。予算の決定者に、作成した設計の価値を証明する際、実際に物理世界で動作する機能設計が必要になります。プロトタイプの動作により得られるデータは、クライアントや設計チームのメンバーと機能要件を調整するために役立ちます。

センサをゼロからシステムに統合し、そこから意味のあるデータを取得するには深い技術的知識が求められるため、多くの場合、予期しない多くの時間と労力がかかります。従来型のセンサ統合の場合、設計が変更になるたびに手間のかかる再構成が必要となります。しかも、設計が変更になるのは珍しいことではありません。特にセンサに関しては、仕様がプロトタイプのニーズに合っているかを確認すること自体が難しい作業です。

プロトタイプにI/Oを追加するのは困難な作業です。カスタムI/Oソリューションの構築に必要な時間とリソースの総コストを予測することは難しいため、プロトタイプ作成プロセスの障害となることがよくあります。

プロトタイプにI/Oを追加する難題を克服するには、取り組み方法におけるパラダイムシフトが必要です。特に低レベルのセンサ通信問題に取り組むだけの専門知識を持たない専門技術者が効率的に試作しようとするなら、やり方を変える必要があります。

NIの統合ハードウェアと直感的なグラフィカルソフトウェア、再構成可能I/Oデバイス、さらに便利なIPやサポートシステムを利用することで、難題を解決することができます。

^{図6: CompactRIOとモジュール式のホットスワップ可能なCシリーズI/Oモジュールを内蔵の信号調節機能と組み合わせることで、プロトタイプにI/Oをすばやく追加可能}

センサ入力と制御出力を機能的プロトタイプに正しく統合できれば、展開と量産に大きく近づきます。それは、製品設計プロセスにおける最大の難関を突破したことを意味します。

アルゴリズムエンジニアリングとは、「アルゴリズムの応用設計」を意味する造語です。​紙​に​鉛筆​で​描​い​た​アルゴリズム​の​素案​を、​信頼​性​が​高​く、​十分に検証された、​使い勝手​に​優れた​実装​に​落とし込む​プロセス​を​指し​ます。​アルゴリズム​を​プロトタイプ​に​実装​し​て​所要​の​機能​を​実現​する​この​作業​は、​製品​開発​サイクル​全体​の​中​で​最も​難しい​仕事​に​なる​かも​し​れ​ま​せん。​しかし、​​大きな​見返り​が​得​られる​作業​でも​あり​ます。実​環境​と​インタフェース​する​I/​O​ハードウェア​を​使​え​ば、​アルゴリズム​が​実際​に​機能​を​果たす​様子​を​自分​の​目​で​確認​する​こと​が​でき​ます。 

アルゴリズム​を機能的プロトタイプ​に​実装​する​の​は​簡単​な​作業​では​ありま​せん。​以下​に​挙げる​よう​な、さまざまな​要因​が​ある​から​です。

プログラミング​の限界​―​高い​I/​O​性能​を​特長​と​する​制御​システム​や​プロセッサ​ (​FPGA​など) iに関して、​通常、​1​人​の​開発​者​が​対応​できる​プログラミング​には​限界​が​あり​ます。異なるプラットフォームのプログラミングには、通常、システムレベルの設計者がほとんどもっていないプログラミング知識が必要です。

基本アルゴリズムの実装―基本機能の低レベルアルゴリズムの実装は時間のかかる作業です。 ところが​プロトタイピング​では​スピード​が​最​優先​さ​れる​ため、​一般に​良く​知​ら​れ​た​アルゴリズム​について​は、​手元​に​既存​の​コード​が​無い​から​とい​って​ゼ​ロ​から​時間​を​かけ​て​新規​に​作成​する​余裕​は​ありま​せん。

複数のプラットフォーム向けにアルゴリズムを作り直す―機能的プロトタイプが進化するにつれて、アルゴリズムを再検討して異なるタイプのシステムに移植する必要が生じます。​プラットフォーム​間​で​ラン​タイム​環境​が​異なる​と​移植​元​の​コード​は​機能​しま​せん。​この​ため、​ある​アプリケーション​を​開発​する​際​に、​プロトタイピング​から​最終​製品​へ​の​実装​まで​の​工程​を通して​段階​的​に​その​アプリケーション​を​拡張​することは困難です。

テストと検証―通常、システムが機能要件を満たしているかどうかは、開発プロセスの終わり近くになるまで分からず、最初からやり直すにはコストがかかりすぎます。​たとえば、​採用​予定​の​プロセッサ​では​必要な数の​並列​タスク​を​十分​な​速度​で​実行​でき​ないこ​と​が判明​する場合があります。十分なサイクル​時間を達成できない​恐れ​が​あり​ます。​また、​プロセッサ​の​負荷​が​高い​解析​について​は、​リアルタイム​で​処理​でき​ない​可能性​も​あり​ます。

LabVIEWグラフィカルシステム設計を採用すれば、​機能的プロトタイプ​作成​時​の​アルゴリズム​エンジニアリング​に​潜む​数多く​の​落とし穴​を​回避​した​り、​その​影響​を​軽減​した​り​する​こと​が​でき​ます。​グラフィカルシステム設計と​は、​グラフィカル​で​直感​的​な​プログラミング​手法​と、​柔軟性​が​高​く​市販​品​ (COTS: Commercial Off-​The-​Shelf) として​入手​可能​な​ハードウェア​製品​を​組み合わせる​こと​で、​設計​上の​課題​を​解決​する​手法​です。この手法を導入すれば、​設計​の​全​工程​を通して1つ​の​開発​環境​を使用​する​こと​ができます。​以下​では、​上記​で​挙​げた​課題​を​この​手法​によって​どの​よう​に​解決​できる​の​か、​詳​しく​説明​し​ます。

演算モデル

グラフィカルシステム設計​の​メリット​の​1​つ​として、​どの​よう​な​演算​モデル (MoC：Model of Computation) で​実装​し​てい​て​も、​プログラマ​が​アルゴリズム​を​作成​できる​という​点​が​挙​げ​ら​れ​ます。​​アルゴリズム​を​実現​する​コード​は​複雑​化​の​一途​を​た​ど​って​おり、​プログラマ​は​コーディング​能力​を​高める​ため​に​さまざま​な​演算​モデル​を​習得​する​必要​に​迫​ら​れ​てい​ます。グラフィカルシステム設計で使用できるMoCの一部を以下に示します。

データ​フロー―データ​フロー​は、LabVIEW​グラフィカル​プログラミング​環境​で標準的に使用される​演算​モデル​です。データ​フロー​では、​開発​者​は​演算​を​実行​する​前​に​すべて​の​入力​に​データ​を​供給​する​必要​が​あり​ます。​データ​フロー​は、その​直感​的​な​コーディング​構造によって、​並列​処理​など​の​アプリケーション​を​容易​に​実装​することができます。

​テキスト​数式​演算―複雑​な​関数​を​簡単​に​記述​できる​ツール​として​は、​この​ほかに​も​テキスト​数式演算​が​あり​ます。テキスト​​数式​演算​を使用する​と、​複雑​な​アルゴリズム​を​スクリプト​形式​で​容易​に​記述​でき、​高い​可読性​も​実現​する​こと​が​でき​ます。​テキスト​数式​演算​の​例​として​は、​フォーミュラ​ノード​や​LabVIEW MathScript RT​モジュール​など​が​挙​げ​ら​れ​ます。​LabVIEW MathScript RT​モジュール​を使用すれば、​アルゴリズム​を​開発​する、​信号​処理​の​考え方​を​検討​する、​結果​を​分析​する​など、​アルゴリズム​開発​の​各​段階​それぞれ​において​最も​効果​的​な構文​を​利用​でき​ます。

^{図7: テキストベースのコードをLabVIEW MathScript RTモジュールで再利用}

Cコード―場合​によって​は、​もともと​​C/​C​+​+言語​で​記述​さ​れ​てい​た​アルゴリズム​を​使う​こと​も​ある​で​しょう。その場合は、​既存の​C/​C​+​+​​コード​を​再​利用​する​こと​が​可能​です。​インラインCノードまたはライブラリ関数呼び出しノードを使用することで、LabVIEW内で前のコードを直接呼び出すことができます。​既存​コード​を​用いる​場合、​あるいは​値​の​小さい​数値​や​配列​アルゴリズム​を​実装​する​場合​に​は、​インライン​C​ノード​を使用します。​DLL​や​共有​ライブラリ​内​の​C​コード​に​アクセス​する​場合​は、​ライブラリ​関数​呼び出し​ノード​を​使用します。

オープンソフトウェアアーキテクチャ

LabVIEW​プラットフォーム​は​長年​にわたって、​さまざま​な​設計​分野​で​広​く​導入​さ​れ​てい​ます。​そのため、​異なる​設計​ツール​や​シミュレーション​ツール​と​のデータ​の​互換性​を​確保​する​必要性​が​高まり​ま​した。LabVIEW​は​それに​応え​て、​多く​の​統合​ツール​や、​ライブラリ、​ファイル​形式​と​の​相互​運用​性​を​確立​し​てい​ます。​さらに、​LabVIEW​は​以下のような多種のソフトウェア​ツール​や​計測​リソース​とも標準で統合されてい​ます。

• DLL、共有ライブラリ
• ActiveX、COM、.NET(Microsoft)
• DDE、TCP/IP、UDP、イーサネット、Bluetooth
• CAN、DeviceNet、Modbus、OPC
• USB、IEEE 1394、RS232/485、GPIB
• データベース (ADO、SQLなど)

これらの​ツール​を​活用​する​こと​で、​ほぼ​すべて​の​計測​器​や​制御​器​から​の​出力​データ​を​統合​する​こと​が​可能​に​なり​ます。LabVIEW​を汎用のハードウェア通信インタフェースの標準規格と組み合わせれば、​開発​者​は​将来​にわたって​互換性​や​拡張​性​を​確保​でき​ます。

LabVIEWを使用した設計手法

LabVIEW​は、​数式​処理​や​信号​処理、​確率、​制御​など​さまざま​な​分野​の​基本​的​な​アルゴリズム​に​対応​した​関数​を​何​百​も​備え​てい​ます。これらの関数を利用すれば、​開発​者​は​低位​の​コード​を​記述​せ​ず​に​すむ​ので、エンジニアは​「ソリューション​の​実装​方法」​では​なく​「ソリューション​そのもの」​に​注力​できる​よう​に​なり​ます。

LabVIEW​を​利用​すると、​実​環境​の​データ​を​とても​簡単​に​集録​でき​ます。​そのため、​実​環境​の​データ​を​使​って​アルゴリズム​を​テスト​し、​アルゴリズム​を​最適​化​する​という​作業​を​繰り返し​行う​際​に​LabVIEW​は​非常​に​有用​です。この​反復​的​な​テスト​手法​では、​異なる​関数​を​試し​て​期待​どおり​の​結果​が​得​られる​か​どうか​を​確認​でき​ます。たとえば、フィルタ​を​用​い​て​信号​を​処理​する​場合、ソリューション​を​幅広い​選択肢​の​中​から​選​んで、​実際​に​必要​な​信号​を​集録​し、​その​結果​を​グラフ​や​ファイル​で​確認​する​こと​が​可能​です。​その​アプリケーション​に​適​した​結果​が​得​ら​れ​なか​っ​た​場合​は、​別​の​フィルタ​を​選択​す​れ​ば​よい​の​です。一般的に​は、​アルゴリズム​に​供給​する​実​信号​を​集録​し​て​から、​ソフトウェア​上​で​シミュレーション​する​方​が​簡単​です。

^{図8: NIのLabVIEWはプロトタイプで使用できる数百の標準アルゴリズムを搭載}

プロトタイプの目的の1つは、潜在的な顧客、投資家、同僚にアイデアとデザインを迅速に見せることです。プロトタイプを作成するもう1つの重要な理由は、基本的なソフトウェアおよびハードウェアパフォーマンスの設計をテストおよび検証することです。多くの場合、問題は、機能的プロトタイプの電気的、ソフトウェア、および機械的なコンポーネントを組み合わせた場合にのみ明らかになります。 

プロトタイプの段階で徹底的にテストすることで、大きなサンクコストになる前に、また、修正が非現実的になる前の早い段階で問題を発見することができます。プロトタイプテストは、パフォーマンスの主張をバックアップするための具体的な証拠を提供し、その結果、自信を持って実装できる信頼性の高い最終製品につながります。

ソフトウェア定義型計測器は本質的に柔軟性があり、自動化が容易です。そのため、今日の製品設計チームは、手動テストにかかる時間を削減し、ラボで必要な計測の量を最小限に抑えることで、開発プロセスを合理化することができます。

LabVIEWグラフィカルソフトウェアプラットフォームを使用すると、メインアルゴリズムの品質と信頼性をテストするための簡単なプログラムを設定できます。プロトタイプを作成する際は、テストの以下の2つの主要な側面に注意してください。

リミットテスト―ソフトウェア設計が、さまざまなデータポイントにわたってI/Oチャンネルで質の高いデータを提供することを確認します。これにより、製品開発サイクル全体を通じてプロトタイプを品質仕様の範囲内に保つことができます。

ストレステスト―品質仕様が長時間の露出で満たされていることを確認し、すべてのI/Oチャンネルが同時に限界に到達することを確認します。アルゴリズムには、処理中のデータが過負荷になっても対処できる堅牢性が必要です。

シミュレーションVIを使用してハードウェアなしでテストすることにより、ソフトウェアアルゴリズムの限界をテストします。これは、LabVIEWさまざまな信号生成VIを使用するか、実際のI/Oを正確に描写するVIを開発することで可能です。

^{図9: I/Oのシミュレーション方法}

データ収集を使用してI/Oを測定する

ソフトウェアテストでは、実際のハードウェアを使用する場合と操作性が異なるため、テストで検証できる内容が制限される可能性があります。LabVIEWを使用すると、COTSハードウェアを使用して、実際のI/Oテストを実行できます。

デジタルマルチメータまたはデータ収集デバイスを使用して、物理ハードウェアI/Oをデバッグすることができます。LabVIEWとNI-DAQmxドライバと組み合わせることで、使いやすく、高レベルインタフェースのDAQmx Express VIを使用して複雑なデータ収集タスクを実行することができます。

^{図10: NI DAQハードウェアを使用したテスト}

アイデアからペーパーデザイン、機能的プロトタイプ、最終的にリリース可能な製品に至るまでの設計プロセスを進めていくことはハードルが高いため、これらの段階間の移行を容易にする方法を見つける必要があります。理想的なのは、実際にデプロイ可能なプロトタイプを設計することです。そうすれば、プロトタイプを数多く生産して配布することができます。これは実際にはあまり起こりませんが、デプロイメントを念頭に置いて設計とプロトタイプ作成を行うことで、設計の重要なコンポーネントがデプロイメントに耐えられるかどうかを確認できます。重要なのは、効果的なプロトタイプに必要な柔軟性と機能を提供するだけでなく、市場に出せるものを作れるような強力でカスタマイズ可能なツールとプラットフォームを見つけることです。

^{図11: 最終製品に近いプロトタイプを作成することが理想}

LabVIEW RIO (再構成可能I/O) アーキテクチャはNIグラフィカルシステム設計プラットフォームに不可欠な要素です。組込監視/制御システムの設計・試作・デプロイメントの最新手法であるグラフィカルシステム設計では、オープンなLabVIEWグラフィカルプログラミング環境とCOTSハードウェアを組み合わせて、開発を大幅に簡素化します。この手法によって、カスタム設計を組み込めるようになり、質の高いアプリケーションを設計できるようになります。

LabVIEW RIOアーキテクチャは、プロセッサ、再構成可能FPGA、モジュール式I/Oハードウェア、グラフィカル設計ソフトウェアの4つのコンポーネントに基づいています。これらのコンポーネントを組み合わせることで、高性能のI/Oを備えたカスタムハードウェア回路を迅速に開発し、柔軟性に優れたシステムタイミング制御機能を実現することができます。多くのNI製品はこのアーキテクチャを採用しています。

^{図12: 柔軟性、信頼性、性能を最大限に高めることのできるLabVIEW RIOアーキテクチャを採用したNIの製品}

Single-Board RIOコントローラは、柔軟性に優れたカスタマイズ性の高いシングルプリント基板です。お客様は、I/O端子、電源、エンクロージャを用意します。Single-Board RIOにより、最終製品へのシームレスなユーザ統合が可能です。さらに柔軟性やコンパクトなサイズが必要な場合は、NI System on Module (SOM) を使用して設計を行うことができます。

^{図13: Single-Board RIO/SOMコントローラは、最大限の柔軟性を提供}

高い堅牢性が求められる場合は、CompactRIOハードウェアが最適です。この工業レベルのハードウェアは、過酷な環境下でも動作することができます。高レベルの衝撃と振動に対応できるデバイスが必要で、そのような過酷な条件下で動作する独自コントローラを開発する時間と費用をスキップしたい場合は、CompactRIOをご検討ください。CompactRIOプラットフォームは堅牢であるだけでなく、Single-Board RIOデバイスで必要なカスタマイズが不要です。電力変換、筐体、I/O端子を独自処理したくない場合にも、CompactRIOが適しています。

^{図14: CompactRIOコントローラは、最大限の堅牢性を提供}

ラボ環境など、より正確な計測を行う場合、またはPCベースのプラットフォームによって制限されている場合には、RシリーズマルチファンクションRIOデバイスが有効です。PCI、PCI Express、USB、PXI、およびPXI Expressフォームファクタで提供されるこれらのデバイスは、Single-Board RIOおよびCompactRIOと比較して優れたI/O信号調節と確度を提供します。Rシリーズデバイスは、LabVIEW RIOアーキテクチャのメリットを活用して、従来のデータ収集ソリューションよりも柔軟に機能を拡張することができます。

^{図15: Rシリーズデータ収集では、標準のPCフォームファクタでLabVIEW FPGAを使用可能}

最大3 GS/秒のアナログまたは1 Gb/秒のデジタルを備えた超高性能I/Oが必要な場合は、FlexRIOが最適です。FlexRIOは、テストコストの削減や組込システムの開発のスピードアップなど、LabVIEW RIOアーキテクチャで最速のI/Oと最大のFPGAを提供し、非常に複雑な試作や実装の課題に取り組む際に有効です。

^{図16: FlexRIOコントローラとモジュールは、最大のFPGA性能とI/O性能を提供}

LabVIEW RIOアーキテクチャは、さまざまなフォームファクタオプションを提供するだけでなく、共通のプラットフォームを共有しています。つまり、LabVIEW RIOアーキテクチャでサポートされている製品に対して同じコードとプロセスを使用し、必要に応じて切り替えることができます。実際、Single-Board RIO、CompactRIO、Rシリーズ、FlexRIOの間で切り替える場合、ほとんどのコードを再利用できます。最終製品のすべての要件が完全に分かっていなくても、試作のプラットフォームの選択を間違った場合ても、すべてのコードを一から書き直す必要はありません。これにより、試作プロセスをより早く開始することができ、開発期間の短縮につながります。また、CompactRIOで試作を開始し、Single-Board RIOに移行して、最小限の機械的リワークを行い、ソフトウェアにほとんど変更を加えずに実装することもできます。これが可能なのは、これらの製品が共通のプラットフォームに基づいているからです。

プロトタイプ作成 (試作) は、組込設計プロセスの中でも極めて重要な部分です。アイデアを製品として実現可能なことを投資家やお客様、会社の経営陣にわかりやすい形で示せれば、予算を獲得しやすくなります。NIのグラフィカルシステム設計ツールは、大規模な設計を行わなくても、機能的プロトタイプを短期間で試作できる便利なツールです。この手順を利用して質の高い機能的プロトタイプを作成することで、次のアプリケーションを早期に軌道に乗せることが可能になります。

関連リンク

• 次のプロトタイプ作成を可能にするNI製品の詳細
• 次のプロジェクトでLabVIEWを使用する方法

Simulink® is a registered trademark of The MathWorks, Inc.