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

記事内容

当コラム記事についての前置き

とある展示会に「工場における人と機械の可視化」を謳ったIoTデモを展示しました。センサーを活用して、データ分析とリアルタイムモニター画面によって作業状態を可視化する展示内容でしたが、それらの様子をコラム記事としてご紹介しました。

参考「工場における人と機械の可視化IoTデモを展示会出展」

上記のコラム記事では、展示テーマや展示内容全体についてご説明する内容となっていましたが、展示内容の一部であるリアルタイムモニター画面は、多彩な動作を伴うために最も説明を必要とするにもかかわらず概要的な情報に留まっていました。

そこで当コラム記事では、リアルタイムモニター画面にフォーカスして、より具体的な情報をご紹介したいと思います。その一方で、「どうしてこのような画面を製作したのか」といった根本的な情報は不足していますので、上記のコラム記事とセットでご覧頂ければ幸いです。

リアルタイムモニター画面の動作を解説

生産作業の状態をリアルタイムに反映して表示（可視化）するモニター画面として製作した「状態監視画面」をご紹介します。

画面構成としては、左側の「作業員カード」列は作業員の作業状態を表示します。他の３列は機械のそれぞれの作業状態を表示します。上図では各作業前の表示と各作業中の表示を例示しています。画面表示について主なポイントをご説明します。

なお、「状態監視画面」が動作する様子が分かる動画も用意しています。文字による説明よりも動画で確認したい方は、次のリンクをクリックすると動画の項目へジャンプします。
動画で観る →

［１］「作業員カード」列の状態表示情報

「作業員カード」列では、次のステータスを通知します。

• 「作業待ち」
• 「作業中」

カードリーダーにカードが置かれていない状態が「作業待ち」であり、置かれると「作業中」になります。

「作業中」の際は、作業員の氏名と「開始時刻」が表示されます。その後カードが置かれている間は「作業時間」（分）が経過表示され、カードが取り上げられると「終了時刻」が表示されます。

［２］機械列の状態表示情報

機械列（３つの列）では、次のステータスによる同一形式で、それぞれの状態を通知します。

• 「停止中」
• 「稼働中」
• 「作業待ち」
• 「作業滞留中」

機械が動作する前は「停止中」ですが、（作業員の操作により）動作開始すると「稼働中」に変わり、（セットした処理が終了して）機械が自動停止すると「作業待ち」に変わります。

「作業待ち」の際に（作業員が機械を操作して）動作開始すると「稼働中」に変わますが、「作業待ち」のまま１分が経過すると「作業滞留中」に変わります。作業員への警告の位置付けになります。なお「作業滞留中」のまま放置すると、設定回数分の警告を行った後には「停止中」の表示に戻ります。

一方で時間表示については、「稼働中」に変わる際に「開始」（時刻）が表示されて、以降は「経過」（作業経過時間、分）も表示されます。

「作業待ち」に変わる際には「終了」（時刻）が表示されて、以降は「停止」（停止経過時間、分）も表示されます。ステータスが「作業滞留中」に変わっても「停止」のカウントアップは引き継がれます。

［３］機械列のセンサー状態表示情報

機械列では「センサー状態」項目で、設置したセンサー（無線モジュール子機）の状態を通知しています。

電波の強度と電池残量をアイコンの色で通知しています。緑色が良好を表し、黄色、赤色と状態が悪くなって行くことを表しています。

［４］音による状態通知

今回のIoTデモにおいては「音」を有効活用することを意識しています。カードをカードリーダー上に置いたり、機械が動作開始・停止するといったイベントでは個別のチャイムが鳴ります。音を聞いただけでも何が起きたか判別できるようにしました。

また、機械の「作業滞留中」時はチャイムではなく、警告音によって作業員の注意を引くようにしています。

その他に、カードリーダー上にカードが置かれた状態では、BGMがループ再生することで作業員に正常状態を伝えます。作業中にBGMが止まっていたらカード置き忘れを意味します。

［５］データ収集のための整合性チェック

今回のIoTデモでは、実績データの収集も行っています。有効な実績データを収集するための監視を当画面で行っています。

有効な実績データとするために、作業員にはカードをカードリーダー上に置いた状態で機械操作を行って貰う必要があります。作業員がカードを置かずに機械操作を行うと、「カードが必要」といった警告表示とブザー音によって作業員に対応を促します。

［６］当画面へのアクセス補助

画面左下にQRコードを配していますが、当画面にアクセスするための情報（URL）です。

展示会場では独自Wi-FiでLANを構成しており、Wi-Fi接続した上でQRコード読み取りをすれば、スマートフォンでも当画面を表示できるようにしています。

可視化IoTデモにおける画面動作の様子

「状態監視画面」の動作について、画像と文字によるご説明だけでは「動きと音」が伝わらないと思いますので、「状態監視画面」の動作にフォーカスした動画を用意しました。

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

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

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]

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

展示会時との違いについて

動画での「状態監視画面」の動作は展示会終了後に撮影しました。実は一部の動作が展示会の時とは異なっています。展示会終了後に改造を行ったのです。

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

動画を見て頂くと「センサー状態」項目は、機械が「開始」した時と「停止」した時だけ色付き表示になりますが他はグレー表示です。

今回のIoTデモの構成では、無線通信を用いてセンサーデータを収集しています。この「センサー状態」項目は、センサーとの通信の状態を通知する項目になります。つまり、この挙動の変化はセンサーとの無線通信の方式に変更があったことの表れとなります。

この無線通信方式の変更について話を進める前に、そもそもどうして改造を行うことにしたのか？についてご説明が必要でしょう。

どうして改造を行ったのか

理由を端的に申し上げると、リアルタイムモニター画面でありながら、機械の動作発生から画面表示反映までのタイムラグが想定よりも大きくなることがあったからです。つまり、表示の遅延が発生しました。

例として、機械が停止してから画面表示に反映されるまで10秒以上掛かったケースも散見されました。通常時は殆ど遅延はないのですが、一度発生すると連続することもありました。

実は展示会準備の段階で既に問題を認識していました。問題を抱えたまま展示会に臨んだことについては後ほど触れますが、展示会が終了したとしても「残った問題点について改善できることはしたい」と考えて改造に取り組みました。

改造の結果を先に申し上げると効果はありました。画面表示のタイムラグは想定範囲内となり、遅延が目立つことはなくなりました。

改造内容は先に述べた通り、無線通信方式の変更となります。それがどうして表示遅延の改善に効果があるのかを順を追ってご説明します。

無線通信の構成が招いた表示遅延

IoTデモにおける無線通信の構成について触れた上で、改造前後の無線通信方式の違いや、表示遅延との関係性についてご説明します。

［１］IoTデモにける無線通信の構成について

センサーとの無線通信について、もう少し具体的に述べます。IoTデモにける無線通信とは、センサーとRaspberry Pi（ラズベリーパイ）^[1]との間の通信になります。

無線機器レベルまで言及しますと、IoTデモに使用した無線センサー製品^[2]では、子機と親機の間の通信となります。よって、加速度センサーを搭載した無線モジュール子機と、Raspberry Piに接続した無線モジュール親機との間の通信ということになります。

IoTデモで使用した無線センサー製品は、１対多の無線通信が可能でしたので親機１台に対して子機３台の機器構成としました。これにはコストを抑える狙いが勿論ありましたが、それだけが理由ではありませんでした。展示会で安定したデモを実現するための選択でした。

IoTデモの観点では、インターネット経由でクラウドサービスを利用して可視化する形式が普通かもしれません。しかし、展示会場の無線通信環境は事前には見通せないので頼りたくありませんし、場合によっては必要な通信速度を保てない可能性もあります。

また、クラウド上での可視化ではリアルタイム性が若干劣りますので、目の前の機械の動作にモニター画面の表示が追い付かずに違和感を与えるデモになってしまう懸念を持ちました。

それらの点を考慮して、独自Wi-FiによるLANを構築して１台のRaspberry Piにデータを集約し、同時に画面処理も行うことが安定したデモの実現に繋がると考えました。またそれは開発する上でも都合が良かったったのです。

［２］無線通信方式の違いについて

IoTデモで使用した無線センサー製品では、子機が送信するデータを親機が受信する形になります。基本的に親機は受け身であり、子機側の設定によってデータ通信の方式が決まることになります。つまり「無線通信方式の違い」と便宜上表現していますが、実際のところは「子機側のデータ送信に関する設定の違い」ということになります。

改造前の設定は、データを一定間隔で随時送信する形でした。便宜上これを「連続通信方式」と称します。

改造後の設定は、（センサー計測値が）しきい値の設定を超えるか下回るかしたタイミングでのみデータを送信する形でした。便宜上これを「イベント通信方式」と称します。

［３］無線通信と表示遅延との関係性について

ここまでの情報を踏まえて状況を整理すると、親機１対子機３の無線機器構成において、「連続通信方式」で通信することにより、画面表示に遅延が発生することがあったということになります。無線通信と表示遅延との関係性について、無線機器側の事情から紐解いて行きます。

使用した無線モジュール子機はボタン電池稼働であり親機はUSB給電でした。これにより省電力稼働を前提としており、そのために無線通信チャンネルの設定は（選択した）１チャンネル固定の仕様でした。これが意味するところは、複数の子機が同時にデータ送信した場合には、親機側では電波干渉の影響により正常にデータ受信できなくなります。

この点については（展示会準備の段階で）メーカーが提供する仕様情報から理解していました。電波干渉が発生することを織り込んだ上で、「連続通信方式」の設定で対策を取りました。

具体的には、３台の子機がデータ送信する間隔を同じにせずに（0.9秒、1秒、1.1秒のように）差を付けました。つまり、「電波干渉を連続発生させない」ことを考慮をした設定にしました。

こうした対策もむなしく、結果は表示遅延として表れました。展示会に向けたテスト時に問題を認識してトラブルシューティングを行いました。そして、親機の受信処理が止まったようになってしまう現象を確認しました。機器の仕様情報に「親機がデータ受信に必要とする処理時間は0.1秒」とあったのですが、それどころではなく秒から十数秒かかるケースも散見されました。

こうした現象を受けた考察として、電波干渉が起きてしまうと親機での受信処理がフリーズしてしまい、処理が再開されるまでに想定外の時間が必要になるようだと推定しました。このため、「電波干渉を連続発生させない」どころではなく「電波干渉を回避する」対策が必要と考えられました。

電波干渉が発生する機会を減らすためには、通信回数を減らすことが有効であることは明白です。よって、「連続通信方式」から「イベント通信方式」への変更が対策になり得るのです。

因みに、IoTデモにおける「イベント通信方式」は、機械が「開始」か「停止」したタイミングでのみデータ送信されることになります。

ここまで分かっていながら、展示会には「連続通信方式」のまま臨んだことになります。これについては準備時間の制約面もありますが、それだけが理由ではありませんでした。

問題点を抱えたまま展示会に臨んだ理由

展示会前に改造を実施しなかったのには、主に２つの理由がありました。

［１］展示会での運営上の利便性を優先した

IoTデモ構成において、データ収集や画面表示の制御はRaspberry Pi上で動作するアプリケーションが行っていました。

当アプリケーションでは、（「連続通信方式」を前提として）受信したデータである加速度計測値を基に機械の開始・停止の判定（厳密には稼働中か停止中かの判定）を行いますが、判定に用いる加速度数値のしきい値をアプリケーション画面上で動的に設定変更できるようにしていました。

これは、展示会場にIoTデモ構成をセッティングした後で、もし調整が必要になった場合でも容易に対応できるようにするためでした。実際のところ画面からの設定変更は展示会の際に役立ちました。

参考までに、設定を行う画面は下図になります。しきい値などの判定条件の設定以外にもカードや機械（センサー）に対してIDと名称の紐づけを行っています。

一方で「イベント通信方式」では、しきい値の設定は子機側で行っています。この設定を変更するためには子機毎にアクセスして行う必要があるのですが、これらの作業が結構手間のかかる作業でしたので展示会場では避けたいと考えました。

なお、「イベント通信方式」と「操作・設定画面」の関係性について補足があります。「イベント通信方式」では、しきい値を基に子機側で機械の開始・停止を判定してデータ送信して来る形になりますが、受信する側では（加速度数値を渡されるだけなので）開始イベントなのか停止イベントが分かりません。そのため「操作・設定画面」の設定値を用いてアプリケーション側で判定を行います。

［２］「イベント通信方式」にも懸念材料があった

「イベント通信方式」では、通信回数を著しく減らすことで電波干渉が発生し難くなりますが、複数子機で同時にデータ送信が行われれば電波干渉は発生します。（意図的に起こすことも難しいレベルのリスクではありますが）

そして、もし発生した場合は「より深刻な問題になる」と考えました。子機からのデータを受信できなかった場合は、子機が判定した結果をロストすることになるのでデモが成立しなくなります。

例えば、機械が停止しても画面表示上は「稼働中」のまま変わらず、不整合な状態がずっと残ってしまいます。

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

上記の例と比較した例えでは、機械が停止した際に表示遅延が発生したとしても時間が経てば画面表示は「作業待ち」に変わるので、不整合な状態は残らないことになります。

目的に照らして複数の選択肢を評価することの意義

リアルタイムモニター画面である「状態監視画面」の動作をご紹介するコラム記事の位置付けでしたが、開発事情の話が長くなったために話の焦点がぼやけてしまったかもしれません。しかしながら、せっかくここまでお話したので、一連の取り組みから得た教訓を共有したいと思います。

それは、「目標（や目的）の設定が意思決定に与える影響の重要性」です。

何かしらの取り組みを進める検討段階では、色々な選択肢が出て来て判断に迷うことも多いと思います。そんな時は、それぞれの選択肢を評価した上で最終的に一つを選択することでしょう。

こうした評価をする上で重要になるのは、「何をするのか」といった目標や目的の設定が明確になっていてブレないことだと思います。今回の取り組みから例を挙げてご説明します。なお、これらの例は選択を失敗したということではなく、目的によって選択は変わることを示すものです。

まず一例として、「連続通信方式」と「イベント通信方式」の選択の件です。

「展示会で安定したデモを行う」ことを最優先して「連続通信方式」を選択したとご説明しましたが、展示会におけるリアルタイムモニター画面を対象としたならば「見る人が違和感を感じないこと」を最優先とする考え方もあるでしょう。その場合は、表示遅延がない「イベント通信方式」を選択することになったかもしれません。

もう一つの一例としては、無線機器構成（親機１台に対して子機３台）を選択した件です。

こちらも「展示会で安定したデモを実現するため」と選択理由をご説明しましたが、そもそも「展示会」という目的に縛られなければインターネット経由によるクラウド上での可視化に支障がなくなります。その場合は、無線機器の親機と子機を１対１にして３セット用意することで、１対３構成で生じた諸々の問題に悩まされることもないでしょう。

２つの例を通じてお伝えしたかったことをまとめます。

どんな選択肢にもメリットとデメリットはあるものです。何を目的とするかの観点によっては、それらが逆転して評価が変わってしまうこともあるのです。

「目的を明確にした上で選択肢を評価することが目的達成への最適な選択に繋がる」

これは当たり前のことを言っているように思われるかもしれませんが、物事を進めて行く内に最初に設定した目的（の意図）を忘れて方向性がブレてしまったりすることはありがちだと思います。

ここで留意点があります。「ブレないことが重要」と伝わったかもしれませんが、最初に決めたことを頑なに変えないという意味ではありません。環境に変化があったり新しい条件が発生したりした場合には、柔軟に方針変更すべきこともあるでしょう。

状況の変化を設定していた目標や目的に照らして、必要なら再設定した上で選択肢を評価して意思決定することが重要だとお伝えします。

そのためにも、目標や目的を設定する際には、意図や経緯まで事細かく記録に残しておくと、いつでも振り返りができて良いと思います。

「初心にかえる」という言葉に重みを感じます。