LabVIEW開発事例組み込みICタグリーダー＆ライター

LabVIEW言語を使用してのプロトタイプ事例を１つご紹介したいと思います。

事例：組み込みICタグリーダー＆ライター

今回の開発したICカードを使った入退出管理器です。機能は以下の通り。

ICタグをこの製品にかざしたら、ICタグにある内容(名前)をLCDで表示する。
赤LED点灯中は読み込み中。緑LED点灯は電源ＯＮ中。
USBメモリには誰が何時にカードをかざしたかあるフォーマットに従い格納。

さて、簡単にプロトタイプまでに至るプロセスを申し上げると、機能と仕様が未完璧(後で必ず変更がある)でもいいので上記のように決定したら、

デザイナーと開発者が外観を決定→モックアップ製作
外観表面に必要なHMI（表示器、LED、ボタン）、機能(アンテナ、センサ)などの部品を選択購入
２で購入した部品はモックアップに正しく組み入れ、本当に完成品に形にする。
３で組み入れた部品をパソコンと直接・間接(I/O)で接続する。
最初の機能を満たすようにLabVIEWでプログラミングする。
機能・仕様を常に詳細議論しながら迅速にプログラミング修正を加える。
6が満たされる時点で、それがそのまま ”動く仕様書” となる

それぞれ簡単に説明すると、

まずは１。
ここは何も申し上げることはありません。ものによっては商品価値はデザインかなぁ。

そして２。今回の電装部品は大きくたったの5点で以下の通り。ＰＣは別ですね。

パーツ名	機能	信号種類
LCDパネル	カード所有者の名前を表示	スイッチ(デジタル)信号
LED	電源状態などを表示	スイッチ(デジタル)信号
スイッチボタン	電源On/Off	スイッチ(デジタル)信号
RFIDカードリーダ	カード読み込み書き込みデバイス	RS232C
デジタルI/O	各スイッチ信号とのやりとり	デジタル信号

そして３。
写真を見て頂ければ、これが完成品であり、未完成品である。ロジックを組み込んでいないという点で。もちろんPCとつなぐ配線とIO部分も完成品では不要ですが。

ついに４。
図１となります。

やっと５。ここからが本番！もう全ての表示・制御はパソコンから出来てしまいます。すごくないですか！そうLabVIEWの出番です。実際は他の言語(VBやC++など)でももちろん問題ありません。しかし、成果への最短距離を走れるのはやはりLabVIEWだ、ということです。

さぁ、どんどんコーディングして機能を確認していきましょう。機能が気に入らなければ、その場で変更してしまいましょう。この変更がその場で容易に出来るということが、今回シリーズで提案しているプロトタイピング手法の核心です。
少しだけ、コーディング内容も見てみましょう。まずはやはり、ICタグに書き込まれた情報を読み出すことから。その部分のコードの一部(弊社販売のRFID開発ツールキット使用)を下図へ。

図にあるのは、開発ツールキットのある１つの関数で、プルダウン形式でその機能が選択出来ます。大変容易にRFIDの開発が可能となっています。実際、これはいわえる関数とであるが、戻り値(return)はたくさんあってもよいことも特徴。もちろん参照渡しも可能。

HMIの部分は図５のようになり、LCD表示部、LED、タグデータの情報を読み込み・書き込みの制御をPCから柔軟に行えるようになっています。ちなみに、文字列をLCDに出す関数は下図のようになっています。

実際、この試作品を直接動かすのはＰＣ側です。そして、どんどんいじりまわしていろいろな意見を”迅速”に反映・変更を繰り返して望む形へと”動く仕様書“が完成していくのです。そして、これを動かしていろいろな意見を収集して下さい。そして、それを集約し反映して下さい。そして、最終仕様と機能を決定し、真の組み込みが開始されます。

最後に

通常、ものつくりの過程において、全体設計→詳細設計→試作→量産といったケースで製品に至る場合をよく想定します。もちろん各社でそれぞれのやり方がありますが、がっちり固定化されている場合が多いのではないでしょうか。ISOでの管理もありますし。そのような中で、試作という工程過程をどれほど重要視しているかは、それこそ各社各部署によって対応は様々だと言えるし、ひょっとしたら単なる通過儀礼としての認識でしか無いケースもあるでしょう。それは、全体設計→詳細設計と渡ってきた過程で試作という工程がもうすでに認識された、いや、暗黙に承認され通過義務を負った１業務上のドキュメントを増やす場面でしかないのかも知れない。簡単に言えば、“もうここまで設計しちゃったんだよねぇ“。

ここまで来るとトップダウン的手法変更を伴わないとなかなか出来上がった組織的構造と手法は変えにくい、というより無理に近い。おそらく読者の諸氏も筆者も経験的にわかることだが、言っていることはまともで効率改善には結び付くとは思うけど、でも、実際各利害関係が複雑でそんなの無理だ、となる。この“プロトタイプ”という題のみで、ピンと来ている読者も実は多いと私は感じています。では、どのような形でこのプロトタイプ(我々は”動く仕様書”と呼ぶ)を進めるか。今後のテーマは、組み込みエンジニアが少しでも楽が出来、かつ、組み込みビジネスが楽しいという将来像のためにもこれは絶対に進まなければならない道を、もっと柔軟性に富んだ、もっと完成度の高い”動く仕様書“という形で提案して取り組んで行きたいと思っています。

ありがとう御座いました。