工場における人と機械の可視化デモ動画と改善情報

記事内容

前回のコラム記事では「人と機械の状態をリアルタイムモニターとデータ分析によって可視化するデモ」をご紹介しました。しかしながら、リアルタイムモニター画面の様子に関しては静止画像と文書では「動きと音」が伝わらないと感じました。この『状態監視画面』の動作を紹介する動画を用意しましたのでご覧ください。

ただ、この動画は『状態監視画面』の動作にフォーカスしている反面、デモの目的や詳細な内容についての説明は十分ではありません。その点は前回のコラム記事と合わせてご覧頂ければ幸いです。

なお、動画について予めお伝えしておかなければなりませんが、この動画は一連の作業を撮影した物ではなく、別々に撮影された素材を編集で繋ぎ合わせています。よって時間軸や動作タイミングの点でカット間の整合性が取れていません。ご承知おきください。

動画の内容（構成）は以下になります。

1. イントロダクション　[0:00-0:07]
2. デモの構成について　[0:08-1:31]
3. 作業員の可視化　[1:32-2:36]
4. 機械の可視化（開始）　[2:37-3:17]
5. 機械の可視化（停止）　[3:18-3:56]
6. 状況に応じた可視化　[3:57-4:41]
7. クロージング　[4:42-4:46]

如何でしたか。やはり視覚的に訴える物については、文書よりも実際に見て頂く方が望ましく、且つ最も効果的に伝える手段だと思われます。今回、映像コンテンツの重要性を再認識しました。手間が掛かっても用意する価値はあると思います。

今回ご紹介した動画について一点補足があります。一部の動作が展示会の時とは異なっています。展示会終了後に改造を実施したことによるのですが、この辺りの動きもご紹介します。

目に見える部分では『状態監視画面』上の「センサー状態」項目（電波状態と電池容量）の表示になります。展示会時は下図のような表示でした。枠で囲った部分のようにデモ中の「センサー状態」項目はずっと色付きの表示でした。

今回の動画を見て頂くと「センサー状態」項目は、機械が「開始」した時と「停止」した時だけ色付き表示になりますが他はグレー表示です。この「センサー状態」項目は、無線センサー子機との通信の状態を表示する項目になります。つまり、この表示の変化は無線センサー子機との通信方式が変更されたことの表れとなっています。

具体的には、展示会時は無線センサー子機が一定間隔で随時送信するデータを受信する「連続通信」方式でしたが、改造後は機械が動作を「開始」した時と「停止」した時だけ無線センサー子機がデータを送信する「イベント通信」の形態になりました。

それでは何故、通信方式を変更することにしたのか？についてですが、端的に申し上げると機械の動作発生から画面表示反映までのタイムラグが想定よりも大きかったからです。例としては、機械が停止してから画面表示に反映されるまで10秒以上掛かったケースも散見されました。見ていて気になったので改造しました。

改造の結果を先に申し上げると効果はありました。画面表示のタイムラグは想定範囲内となり、目立つことはなくなりました。改造内容は「表示タイムラグ軽減の対策として通信方式を変更した」となりますが、タイムラグと通信方式の関係性をご説明する必要があるでしょう。タイムラグが発生した経緯を補足して行きます。

今回使用した無線センサー製品^[1]は、１対多の無線通信が可能でしたので親機１台に対して子機３台の機器構成としました。ただ、子機はボタン電池稼働であることから省電力稼働を前提としており、その為に無線通信チャンネルの設定は１チャンネル固定になります。これが意味するところは、複数の子機が同時にデータ送信した場合は親機側では電波干渉の影響により正常に受信できなくなります。

この点についてはメーカーが提供する仕様情報から理解していたので、（展示会時は）電波干渉が発生することを織り込んだ上での対策として、３台の子機がデータ送信する間隔を同じにせずに（0.9秒、1秒、1.1秒のように）差を付けました。因みに機器仕様によれば、親機がデータ受信に必要とする処理時間は0.1秒とのことです。

展示会時は「電波干渉を連続発生させない」考慮をした設定としていたのですが、結果はタイムラグとして表れました。現象を受けての考察として、電波干渉が起きてしまうと通信が再開されるまでに時間が必要になるようだと推定しました。そこで電波干渉が発生する機会を減らす為に通信回数を減らす対策を取った訳です。

実際の対策は無線センサー製品の設定変更になります。「子機側に設定したしきい値を基に子機側で判定した結果によりデータ送信する」ように設定したことで、加速度の数値がしきい値を超えた時だけデータ送信される「イベント通信」方式となりました。

実は展示会の時点でもタイムラグ改善の策として「イベント通信」方式への変更を検討していました。しかし、展示会においては無線センサーとの通信では一定間隔での「連続通信」方式で臨みました。それには主に２つの理由がありました。

まず１つ目の理由は、展示会でのデモ運営上の利便性を優先しました。具体的には機械の開始／停止の判定をRaspberry Pi（ラズベリーパイ）^[2]上で動作するアプリケーション側で行うこととし、加速度数値のしきい値設定をアプリケーション画面上で動的に変更できるようにしていました。

これにより、展示会場にデモ構成をセッティングした後で、もし調整が必要になった場合でも容易に対応できると考えました。一方で「イベント通信」方式では子機毎に設定が必要であり、加えて設定変更にも手間が掛かることが分かっていました。

実際に展示会では画面からの設定変更は役立ちました。参考までに、設定を行う画面は下図になります。しきい値等の判定条件の設定以外にもカードや機械（センサー）に対してIDと名称の紐づけを行っています。

『操作・設定画面』について補足します。「イベント通信」方式への改造により無線センサー子機側で判定することになったのであれば、画面側にしきい値設定は不要なのでは？と思われた方もおられるでしょう。しかし、結果的に画面側に加速度数値のしきい値設定は残りました（形式は変わりましたが）。発生したイベントが「開始」なのか？「停止」なのか？を加速度数値の大きさによって判定する必要があった為です。

そして２つ目の理由は、「イベント通信」方式でも電波干渉のリスクは残っており、もし発生した場合は「より深刻な問題になる」と考えました。どういうことかと言いますと、通信回数が減っても複数子機で同時にデータ送信が発生すれば電波干渉が起こります。そして子機からのデータを受信できなかった場合は、子機が判定した結果をロストすることになるのでデモが成立しなくなります。

一方で「連続通信」方式では、子機は加速度数値を送信するだけであって判定はアプリケーション側で行います。加えてアプリケーションでは数値の経過を観察して判定を下しているので、何件かデータをロストしてもデモが成立しなくなるような致命的な問題は避けられると考えました。

どうして問題点を抱えたまま展示会に臨み、終了後に改造を行ったのかをご説明しましたが、話が長くなって分かり辛くなってしまったかもしれません。技術的な内容は置いておいて話の主旨を整理します。

• 展示会では「デモを安全に実施することを最優先する」選択をした
• 展示会終了後に「別の選択肢も実際に試してみよう」との動機もあって改造を実施した
• 改造による効果は得られた

『状態監視画面』はリアルタイムモニター画面ですので「見る側の方が違和感を感じる状態」は極力避けなければなりません。その観点からはタイムラグが少ない改造後の状態で展示会に臨んだ方が良かったかもしれません。同時通信が発生しないように展示員が留意して機械操作をすれば、致命的な電波干渉の問題も回避できたでしょう。結果論ですが。

ただ、どんな選択肢にもメリットとデメリットがあって、何を目的としているかによっては、それらが逆転することもあります。展示会のように「見た目重視」の選択の場合もあるでしょうし、「見た目よりも判定ミスを絶対に起こさない」ことが優先される場合もあるでしょう。

今回の取り組みを通じてお伝えしたいポイントは「目的を明確にした上で複数の選択肢を実際に試し、得られた情報を考察して目的の達成に最適な選択を行う」ことが良い結果に繋がると考えます。