本記事の概要
前編では、頻繁な電池交換が困難な現場制約を受け止め、「バイナリパッキング」による圧縮と、「SDカード保存を盾にした全件再送の破棄＋最新値優先」というエッジ、通信層のトレードオフについて記載しました。
しかし、通信を割り切ることは「現場での運用負荷を放置すること」と同義ではありません。通信が途絶した際、Web監視ダッシュボード側で適切に異常を捉え、現場の人間が迷わず、かつ焦らずに対処できるオペレーションへ繋げられることも、システム開発の一部であると考えています。
後編となる本稿では、「切れた通信を現場運用でどう救うのか」に焦点を当て、ダッシュボード監視における動的UI制御と、非IT層の作業員でもミスを起こさない運用手順書を連携させた「二重防御」について下記項目に分けて記載します。
- リトライ制御
- 動的UI
- 正常稼働の定義
本記事の事例は、私が主導する「HWとSWが密結合するIoTシステム」の開発に基づいています。センサーの生データをバックエンドで加工し、WebUI上に可視化・制御する構造を持つシステムにおいて、1人目のSWエンジニア兼PMとして、初期設計から段階的リリース完走までの全体プロセスを統括した実践知を体系化しています。
リトライ制御による恒久通信障害の検知
受信側（クラウド・サーバー）は、単にデータを吸い上げるだけでなくデバイスへ指示を行う立場でもあるため、無応答を放置せずダッシュボード上でエラー通知を確認できる必要があります。
- リトライ制御による段階的判定:
電波の微弱な現場では一時的な瞬断が無視できません。1回の通信途絶で即座にエラー通知を飛ばすと、現場は「オオカミ少年」状態に陥り、アラートを無視するようになります。本システムでは要求側で数回のリトライを実施し、瞬断を除外した上で「高確率で恒久的に通信不良になっている状態」のみを正確に検知します。 - 視覚的認知の向上:
恒久異常と判定されたデバイスは、ダッシュボード上の該当項目の背景色を変更し、管理者が多数のデバイス一覧の中から瞬時にトラブルを判別できるようにしています。
動的UIと手順書連携の二重防御
異常を検知した後に対応するのは運用者、現場の人になります。システム制御と運用手順書を連携させ、現場の迷いとミスを構造的に排除することを考えました。
- 動的UIによる二重操作防止と待機誘導:
ダッシュボードには遠隔リトライボタンを実装しており、異常検知時はその実行を促します。ただしボタン押下後は、データの反映時間目安（例：最大10分）を表示して所定時間経過後に画面を再確認するよう誘導します。また、処理待ちの間に焦った作業員がボタンを連打しないよう、同一処理を行うボタンを非活性化（グレーアウト）し、待機メッセージを表示して物理的に誤操作を防ぎます。 - ステータス遷移と特定異常メール通知（章・ページ番号連携）:
所定時間が経過してもデータが更新されない場合は、画面上に「データ回収（SDカード回収）をすべきである」旨の状態表示を行います。同時に、特定異常時のメール通知機能を活用し、機器判別情報、最終データ取得日時、想定される状態、そして該当するリカバリ手順を運用者へ即座に届けます。この際、作業員が分厚いマニュアルを探し回る無駄を排除するため、参照すべき運用手順書の「該当章番号・ページ番号」までピンポイントで指定し、現場の探索時間をゼロにします。 - 「画面キャプチャ＋赤枠強調」の運用手順書:
本機は少し特殊な機器であり、エンドユーザー側で実施できる復旧作業は一部（電源再投入等の一次切り分け）に限られます。そのため、非IT層の作業員でも迷わないよう、説明文書とともに「実際の画面キャプチャと赤枠線での確認箇所強調」を用いた運用手順書を整備しています。待機が発生する箇所も手順書内で赤枠やアイコンで強調し、現場の焦りによる電源の入れ直しなどを防ぎます。
管理画面インポートと正常稼働の再開定義
現地でSDカードを回収した後のフローと、「何をもって復旧とするか」の定義をあらかじめシステムに組み込んでおくことが重要です。
- 管理画面からのインポートによるデータ補完:
回収したSDカードのデータは、専用ツールではなく普段のWeb管理画面から直接インポートできるようにしています。これにより、欠落していた期間のデータを安全に補完し、データの連続性を維持します。 - 客観的事実に基づく「正常稼働」の再開判定:
重要なのは、「データ回収やインポート自体は運用の正常化ではない」という点です。インポートはあくまで過去の記録を救済したに過ぎず、通信が途絶した根本原因が取り除かれていなければ、以降のデータが正常であると保証できません。顧客側で実施可能な一次対応（電源再投入等）を経て、「通信経由での新規データ取得再開が確認できたこと」をもって初めてシステムが正常稼働を再開したと客観的に判断します。
振り返り
成果
IoTシステムの便利さの裏には、何か不具合が発生した時の判断や調査がすぐには行えない、という運用保守の難しさが潜んでいました。
運用現場で使用してもらうためにはシステムとしての便利さを享受しながらメンテンナスを正確に、業務を止めないで行えるための仕組みが必要であることを痛感しました。
Webシステムのように「何かあったら発生事象を確認してログを取得して解析する」、このような対応はIoTシステムに対しては一部にした通用せず、その空白部分を埋めるために様々な仕込みをしなければいけないことを学びましtた。
振り返り
- 必ず発生するエラーに対してはその頻度に対して「誰に」「どのような」通知をしなければいけないかを考える
- システム上で「次は何をしなければいけないか」を明確にする
- 不具合対応は事象によっていくつかの対応に分かれる（データ取得、インポート、など）可能性がある、それと同一レベルで「正常稼働」のための手順を明確にする