工場現場システムのオフライン設計 — 落ちる Wi-Fi を前提に、止まらない現場をどう作るか

タイの工場でモバイル対応の現場システムを本番運用すると、ライン Wi-Fi は必ずどこかで切れます。金属ラックの間、大型機械の裏、分厚いコンクリート壁の向こう側。加えて、拠点によっては昼休みに 200 人の作業員が一斉にスマホを取り出した瞬間、共有回線がスッと細くなって 20 分ほど戻ってこない、といったことも実際に起きます。

こうした環境で「ネットワークがいつも動いている」ことを前提にしたシステム設計にすると、稼働開始後にラインが止まります。本コラムでは、当社が 工場出荷ラインの QC スキャンシステム を含む複数のタイ工場向け案件で学んだ、"ネットワークは切れて当たり前" と見なして現場システムを作る考え方を、なるべく具体的な現場のシーンとあわせてまとめます。

まず、典型的な 3 つの失敗の仕方

「オフラインでも動くように作りました」と言われているシステムでも、実際に稼働させると、次の 3 つのパターンで問題が出ることがよくあります。

1. 回線が切れた瞬間、画面が固まる

作業員がスキャンして「決定」を押したところで、画面の真ん中でぐるぐる回るローディングが延々止まらない。次のスキャンに進みたいのに、進めない。数十秒待って、諦めて画面を再読み込みすると、直前のスキャンは消えている。

これは、システムの中で「サーバーの返事を素直に待つ」だけの作りをしていると起きる、単純な話です。通信が途絶えた瞬間に、その "待ち" が永遠に終わらなくなる。作業員から見ると、システムが「黙り込んだ」ように見えます。

2. 見た目は動いているのに、実は何も保存されていない

1 番目より厄介なのが、こちらです。作業員がスキャンし、確認画面が出て、次に進んでいる。本人は完璧に仕事をしたつもりでいる。ところが 1 時間後、現場管理者が事務所のダッシュボードを見ると、この 1 時間で登録されたはずのスキャンがゼロ件。

実は、回線が切れた時点でシステムはローカルにだけ書き込みを続けていて、サーバーには 1 件も届いていなかった。そして、その状態が「異常」として作業員側の画面に一切表示されていなかった。ここまで来ると、検品されたことになっていない箱を積んだトラックが、もう工場を出てしまっている、という状況になり得ます。

3. 電波が戻ったとき、データが二重になったり、消えたりする

回線がつながって、ためこんでいたスキャンが一気に飛んでいく。ここで日常的に起きるのが 2 つ。ひとつは、「送信ボタンが効かないと思って何回か押してしまった作業員がいたので、サーバー側に同じスキャンが 2 - 3 回登録されていた」という重複。もうひとつは、「管理者がその間に事務所側でマスタデータを直したのに、古いコピーを持っていた端末が同期のタイミングで元に戻してしまった」という上書き事故です。

この 3 つはそれぞれ別の場所で起きる問題なので、対応も別々に打つ必要があります。ここから先は、私たちが実案件でどう現場システムを作っているかを、ひとつずつ書いていきます。

対策 1. 端末側で先に「この操作の背番号」を決めておく

作業員が 1 回のスキャン、1 回の報告、1 回の承認を出した瞬間に、その "操作" 単位に固有の背番号 (実際には長い文字列) を、端末側で先に発行してしまうようにシステムを組みます。

この背番号は、後でサーバーに届いたとき、「以前に届いた同じ背番号のものと同じなら、それは 2 回目以降だから何もしない」というルールで扱われます。作業員が焦って送信を 3 回押しても、通信の再送で 2 回届いても、サーバー側の記録は 1 件だけ。

ポイントは、この背番号を "端末で" 決めることです。「サーバーに問い合わせて背番号をもらう」設計にしてしまうと、通信が切れているときに操作そのものを完了させられません。オフライン対応のためにどれだけ他の仕組みを積み上げても、この最初の一歩で崩れると、意味がなくなります。

対策 2. 作業員には「オフライン中です」を見せない

「今、オフラインです」というアイコンやメッセージを画面に出すのは、良かれと思ってやりがちですが、現場では逆効果になることが多いです。

タイの工場で朝から夕方まで箱を出荷し続ける作業員に、いちいち「今つながっているか」を判断させると、認知の負担が積み上がります。エラーの原因を「回線か? 操作ミスか?」と迷い始めた瞬間、ライン全体のペースが落ちます。実際にあった話として、作業員がシステムを信用できなくなり、"念のため" と紙にもメモを取り始めた瞬間、そのシステムを入れた意味の半分は消し飛びました。

当社が現場で採っている作り方は逆で、作業員から見た画面からは、オンラインもオフラインも消してしまう方向です。スキャンして「決定」を押したら、その情報はまず端末の中にちゃんと確定として記録されます。画面はすぐに次に進みます。実際にサーバーへ送るのは、システムの裏側でこっそり動いている別の担当が引き受けます。作業員から見えるのは、いつもと同じ、動いている画面だけです。

一方で、事務所側のダッシュボードでは「今、まだサーバーに届いていないスキャンが 47 件、最も古いのは 12 分前」というふうに、状態を明確に見せます。作業員と管理者では、必要な情報が違うので、責任範囲を分けます。管理者は、この数字が増え続けていれば「ライン止めて事務所に集まって」と判断できるべきです。

対策 3. データの種類ごとに、同期のやり方を変える

「サーバー側では、後から来た書き込みが常に正しいことにする」— これは実装は楽ですが、現場では事故を招きます。データの種類によって、同期のやり方は変えるべきです。

ログのように「後ろに足していくだけ」のデータ

検品ログ、スキャン履歴、作業報告のようなデータは、書き換えることがなく、ひたすら記録が増えていくだけです。この種類のデータは、順番が多少前後しても、後ろに足していけば済みます。競合は原理的に発生しません。工場システムで扱うデータの大半は、実はここに入ります。一番シンプルに扱えるカテゴリです。

マスタのように「上書きされる可能性がある」データ

Part 情報、ユーザーの権限設定、単価の設定などです。ここで「後勝ち」ルールを採用すると、例えば以下のようなことが起きます。

朝 10 時、管理者が事務所で「A 部品の単価を修正」しました。同じ時間、出荷ラインのスマホは電波が切れており、A 部品の古い単価をキャッシュとして持っています。昼、電波が戻ったスマホが「私が持っている A 部品の情報を送ります」とサーバーへ送信すると、朝管理者が直したはずの単価が、古い値で上書きされて消えます。誰も気付かないまま 1 週間が過ぎ、経理チームが「なぜあの請求書が旧単価で出ているのか」と首をひねる、というところまで進んでからようやく発覚します。

これを避けるには、「そのデータには今、何回目の更新版が入っている」というバージョン番号を持たせて、古い版から来た更新は問答無用で弾く、という判断をシステムに組み込みます。

数のように「積み上がっていく」データ

作業員 A が箱に 5 個入れ、作業員 B が同じ箱に 3 個追加した、というカウント系のデータです。ここで各端末が「今、この箱には 5 個です」「今、この箱には 3 個です」と絶対値で送ると、後着の方が前の値を上書きして、合計が正しく積み上がりません。

この種類のデータは、絶対値ではなく「+5」「+3」という増減で送り、サーバー側で足し算するようにシステムを組みます。順番が前後しても、通信が途中で切れて再送になっても、最終的な合計はずれません。

対策 4. 開発中に、意地悪に回線を切って試す

ここまで書いた話は、机上で正しく設計するだけでは足りません。実際に手元の端末で意地悪に試して、はじめて分かります。

私たちが検証のときに必ず踏むのは、次の 3 つのパターンです。

1. 操作の途中で回線を切る — フォームを埋め終わって送信ボタンを押した直後、スキャンを 1 個読み込んだ瞬間、次の画面に切り替わるアニメーションの最中。こういう「絶対にここで切れないだろう」というタイミングで意地悪に切ってみます。
2. 切れたままで 5 - 10 件の操作をため、その状態から一気につなぐ — 現場では、Wi-Fi が 30 分完全に落ちて、復旧した瞬間にたまっていた操作が雪崩のように飛んでいく、というシナリオが実際に起きます。この "雪崩" でシステムが崩れないかを見ます。
3. 端末 2 台で、同じデータに同時に操作を加えてから両方復旧させる — これが一番、後から泣くパターンです。作業員 A の端末と作業員 B の端末が両方オフラインで、それぞれ同じ箱について別の入力をしていた、というケースをわざと作って、どちらのデータもきちんと残るかを確認します。

本番でしか出会わない不具合の多くは、この 3 つのシナリオを開発中にきちんと踏んでおくと、事前に気付けます。逆に言うと、この 3 つを踏まずに納品されたシステムは、本番でどれかにぶつかります。

まとめ

タイの工場で現場システムを設計するとき、「回線は基本的に安定していて、たまに切れる」ではなく、「回線は必ず切れる。切れているのが普通の状態」から出発するのが、実務上一番安全です。この最初の前提を変えるだけで、その先の判断がすべて自然に変わっていきます。

本コラムで書いた 4 点 — 端末側の背番号、作業員の画面からオフラインを消す設計、データ種別ごとの同期の作法、意地悪なテスト — を最初からシステムに組み込んでおくと、稼働開始後に「ライン止まりました」という電話を受け取る回数が大きく減ります。特にバンコク近郊やイースタンシーボードの工業団地では、雨季に基地局の一時不調で近隣一帯の LTE が数十分落ちる、といったことも起きるので、"完璧なネットワーク" を前提にしたシステム設計はどこかで裏切られます。

関連: 工場出荷ラインの QC スキャンシステム / 工場業務改善システム

タイの工場向けの現場システムをご検討中の方、お問い合わせ からお気軽にご相談ください。