3月くらいから近隣の某PCショップの方と中小企業向けIoT普及に向けての打ち合わせを何度か行っている。その中で何らかデモが必要だろうということで、デモ機を作成することにした。

　実はデモ機は、別の用途で既に作成済みであったが、あまりに手作り感満載の代物だったので、もうすこし見栄えの （少なくてもケースに入っている状態）するものを作りたかった（動画）。

　IoTのコアはWiFi通信だが、これはESP-WROOM-02を使えば問題はない。だが、このESP-WROOM-02の欠点は、アナログ入力ピンが1つしかないことだ。

したがってこの部分は、A/Dモジュールを追加して補強する。ESP32を使えば必要ないのだが、まだライブラリ関連に不安があるので、手が出しづらい。

今回は、工場での使用をターゲットにしているので、盤内のDC24Vを電源として使うことにした。IoTでやっかなのは、この電源の確保だ。

IoT機器のために電源の配線工事が必要だと、設置だけでそれなりの費用がかかってしまう。盤内の電源を使えれば、この部分は比較的簡単に済ませられる。これらをワンパーケージにして、IoTベース基板の仕様が固まった。

写真はベース基板。小ロットに対応できるようDIP部品だけで構成した。

○シールド基板（子亀）

　IoTの場合、何を感知させるか、具体的にはどのセンサーを付けるかが悩ましい。このため最初からセンサーを込むような出来合いのものが作りにくい。今回は、親亀 （ベース基板）と小亀（拡張基板）の2部構成にした。この方法なら子亀を変えれば、かなりのセンサーに対応することができる。

今回はデモなので、シールド基板として作成した。

写真はケースに親子基板を取り付けたところ。このケースは壁面取付用のミミがあるので大きく見えるが、箱部分の面積なら名刺よりも小さい。

　IoTのハードウェアはそれほど難しくはない。基本的にモジュールを集めればできてしまう。問題は、ソフトウェアの方だ。従来の組み込む型ソフト（ファームウェア）というのは、出荷時に書き込んだままで更新しない。

　今でこそスマホでは、当たり前のように端末のファームウェアを書き換えているが、これは通信装置が組み込まれていることが前提になっている唯一に機器だからだ。IoT機器も同様なので、同じようなしくみを持たせることができる。というよりそれをフルに活用しないと運用後に、たぶんやっかいな問題が発生することになる。

IoT機器で取集されたデータは、Azure IoT HUBに送信することにした。通信で厄介なのは、送信と受信の両方のプログラム開発が必要になることだ。

ただAzureを使うことで、受信部分は、とりえあず作らなくてすむ。それに社内に新たにサーバーを設置しなくていいので、イニシャルコストが安く、機器の保守もいらない。集計プログラムは、当社の担当ではないが、Webアプリで開発することになると思う。そうすることで、社内外を問わずに、結果を表示させることができる。

　たとえば、IoTからの情報がPCで表示されなくなったとする。たぶん、たいていのエンドユーザーからは「壊れたから、見に来てくれ」としか連絡がない。だがIoT機器とAzureを組み合わせると、下記のようなことがエンドユーザーに出向く前に調査できる。ファームウェアの問題であれば、改修し、更新までをリモートで行うことができる（すでにデモ機に実装済み）。

IoT機器は台数が多くなると、かならず、保守の問題がでてくる。この保守への対応をしておかないと後々面倒なことになる。

　IoTというのは、双方向通信機能をもった機器だ。実際に運用しだすと、便利さを実感できるのだが、それを事前に伝えるのがなかなかむつかしい。

ここでは当社の社内設備"ホイスト停止警告器"を、一例としてみる。

　先日、運用を開始し、社員向けに簡単な説明書を書き始めたのだが、どうにも説明がやっかいな部分がでてきて困ってしまった。あれこれ、考えたが、結局、説明書ではなく、仕様を変えてプログラムの方を書き換えることした。通常なら、6メール上の天井に設置してある機器のファームウェアを書き換えを行く気は、まったく起きないのだが、WiFi経由で書き換えられるので、椅子から立たずに作業が完了してしまった。もちろん、試運転も必要なので、これは現場に出向き、ノートPC片手にパラメータをいじって、ものの10分くらいで終了した。

　もう、この程度のことは、自分的には当たり前になっているが、もし、従来の組み込み型機器の場合だったら、説明書の方で"仕様"と称して、絶対にファームウェアを書き換えようとは思わなかっただろう。このことは、見積りの甘さから、利用者側に不可解な"仕様"を押し付けるという従来の悪習が、IoTによって軽減できるのではないかと感じさせるできごとだった。