タイの工場でセンサーを増設し、画面に温度や圧力が表示された。ところが、品質監査で「このロットの加熱中に値が途切れた30分を説明してほしい」と問われると、誰も答えられない。工場センサーデータ欠測対策の導入では、通信できたかどうかより、期待した記録を数え、欠けた理由を識別し、復旧後の記録を照合できるかが成否を分けます。本稿はセンサーの種類やPLCから値を取り出す経路ではなく、発注時の要求仕様と工場受入試験に焦点を当てます。
「欠測ゼロ」を契約に書く前に、何が欠けたかを決める
温度を1秒ごとに取得する設備と、値が変わった時だけ通知する設備を同じ「1秒間に1件」で評価してはいけません。前者では、操業時間内の予定スロットに記録が無ければ欠測候補です。後者では、変化がない間に記録が無いことは正常で、通知の連番、通信セッションの状態、周期的な生存確認など別の観測が必要です。測定方式を無視して「受信件数が多いほど良い」とする評価は、記録を重複送信する実装を有利にしてしまいます。
最初に、データごとに「いつ、何件を期待するか」を台帳へ書きます。固定周期、変化時、設備イベント、手入力のどれか。設備の停止時間を分母から除くか。立上げ・洗浄・品種切替の時間を別扱いにするか。欠測の判定を速報で行う時点と、遅延到着を待って確定する時点を分けるか。これらはシステムの初期設定ではなく、品質部門と現場が合意すべき業務上の条件です。
例えば「稼働中に温度を10秒周期で記録する」と決めたなら、1時間の予定件数は360件です。受信側に342件だけ見えた時、速報の完全性は342÷360＝95%です。ただし18件がエッジ機器に残り、後から全件到着する可能性があります。「速報時点の完全性」と「確定時点の完全性」を分けて記録すれば、通信断と恒久的なデータ消失を混同しません。この数字は説明用の例であり、どの工場にも適用できる合格値ではありません。
工場センサーデータ欠測の場所を6段階で切り分ける
センサーからダッシュボードまでは一つの通信路に見えても、実際には故障点が複数あります。測定そのものが失敗した、PLCやロガーは測定したがゲートウェイが読み落とした、ゲートウェイは受けたがバッファに書けなかった、バッファにはあるが送信できない、送信したが受信側で拒否された、保存されたが集計画面に出ない、の六段階です。最後の例では原データは存在するので、欠測というより表示や検索の問題です。工程をまたいで一つの「欠測率」にすると、誰が直すべきかが分からなくなります。
一件の記録に最低限必要なのは、設備・タグを識別するID、値と単位、計測時刻、受信時刻、品質状態、元イベントを識別するキーです。設備側に連番が出せるなら記録し、再送で同じ連番が来た時に重複と判定します。連番を出せない機器では、ソースIDと計測時刻だけで一意性を保証できるとは限りません。周期内に複数イベントが起きるためです。適切なキーは機器の仕様と対象データを確認して決めます。
OPC UAのDataValueは値に加えStatusCodeと時刻を扱い、監視項目のキューから通知が破棄された場合は条件に応じてOverflowビットで知らせる仕様があります。したがって、受信側は値だけを保存して品質情報を捨てるべきではありません。ただしOverflowが付かないことは、センサーから最終保存先までの無欠損を証明しません。監視キューより前後に別の故障点があるからです。仕様に応じて各境界のカウンターとログを取得し、障害位置を狭めます。OPC UA DataValueとMonitoredItemのキュー仕様は、この確認の出発点です。
データ完全性・遅延・品質を別々に測る
欠測対策の見積で「可用性99.9%」という一行だけでは判断できません。設備の稼働率、ネットワークの接続率、期待スロットに対する記録完全性は別物です。発注側は対象タグごとに次の四つを定義します。
- 暫定完全性：観測期限までに到着した有効な一意記録÷予定件数。現場画面で今すぐ使えるかを見る。
- 確定完全性：復旧猶予後に照合できた有効な一意記録÷予定件数。品質・監査記録として使えるかを見る。
- 到着遅延：受信時刻−計測時刻。中央値だけでなく上位側の分布も見て、アラートや判断に間に合うか確かめる。
- 品質率：Good、Uncertain、Bad、推定、手補正を分けた件数。数値が存在しても信用できるかを見る。
「有効な一意記録」の定義を曖昧にすると、Bad品質の値や再送された重複まで分子に入ります。欠測区間を補間した値は分析には役立ちますが、実測値に変身させてはいけません。原データ、推定値、手補正値を別の品質フラグと監査履歴で残します。ヒストリアン製品も値・品質・時刻を一組で保持し、記録モードやデッドバンドによって保存件数が変わります。画面上で点が滑らかにつながっていても、原記録が等間隔に存在したという意味ではありません。IgnitionのTag Historian説明はこの区別を明示しています。
計算例を一つ示します。10秒周期で8時間稼働すれば、予定件数は2,880件です。締切時に2,840件が届き、うち10件が重複、5件がBad品質なら、契約がBadを除外する場合の有効件数は2,825件、暫定完全性は約98.09%です。後から40件が届いても、そのうち同じイベントの再送が6件なら、純増は34件です。確定有効件数は2,859件、確定完全性は約99.27%になります。どの数字を契約に使うかは用途別に決めます。品質保証記録と省エネ傾向分析では、許容条件が同じとは限りません。
時刻設計は「いつ測ったか」と「いつ届いたか」を分ける
後から届く記録を正しく並べるには、計測時刻と受信時刻を二つとも保存します。ゲートウェイがセンサーを読んだ時刻しか分からない場合は、その時刻を計測時刻と偽らず「ゲートウェイ観測時刻」と明示します。時計の出所、同期方法、タイムゾーン、許容誤差、同期失敗時の扱いもタグ台帳に入れます。タイ工場と日本本社で画面を共有するなら、保存時刻はUTCなどの一つの基準へ正規化し、表示で各地域の時刻へ変換すると照合しやすくなります。ただし既存設備の時刻を強制変更する前に制御側への影響を確認します。
タイムスタンプの精度が1秒なのに、100ミリ秒間隔のイベントの先後関係を議論することはできません。逆に、秒単位で十分な温度監視に高価な時刻配信構成を無条件に入れる必要もありません。工程上の問いから必要な分解能を決めます。「異常停止の前後関係を調べる」「滅菌工程の温度保持時間を証明する」「製品ロットに検査値を結び付ける」は、それぞれ必要な時刻情報と許容遅延が異なります。時刻同期そのものの設計は別テーマですが、本稿では時刻の由来を欠測判定と受入試験に組み込みます。
記録が受信先に遅れて到着した時、元の計測時刻を書き換えないことが重要です。再送が成功した時間は受信時刻に残します。「14:00に測り、14:37に届いた」と追える構造なら、14時台の工程記録として扱いつつ、37分間は速報画面に無かったという事実も説明できます。両時刻の差だけでは時計ずれと通信遅延を区別できないため、同期状態の記録も必要です。
エッジバッファを容量ではなく復旧手順まで設計する
「通信断でも保存」と書いた提案書を見る時は、どこに、何時間、何件、どの順序で保存し、ディスク満杯で何を捨てるかまで確認します。揮発メモリだけのバッファは再起動で消える可能性があります。ディスクに保持する場合も、容量、書込み寿命、権限、暗号化、破損時の復旧、停電時の動作が残ります。優先タグを先に送ると低優先タグの遅延が伸びるため、優先順位も明示します。
容量見積の最小形は「平均記録サイズ×毎秒件数×保持秒数」です。例えば1件200バイト、毎秒50件、保持24時間なら、生データだけで864MBになります。実装ではインデックス、ファイル形式、ジャーナル、予備領域、再送中の新着分が上乗せされるので、この数字をそのままディスク容量にしてはいけません。実測した書込量と復旧帯域で見積を補正します。24時間分を貯められても、通常流入と同じ速度でしか吐き出せなければ滞留は解消しません。復旧帯域から通常流入を差し引いた純処理能力で追いつく時間を計算します。
AWS IoT GreengrassのStream Managerにはストリームの永続化、サイズや保持期間、切断時の振る舞いなどの設定があります。これは製品で利用できる機能の例であり、どの現場でも自動的に全件回復するという意味ではありません。設定値、対象ストリーム、送信先の受入能力、エッジ装置の障害を含めて試験します。AWSのStream Manager資料を比較表の参照先にできます。
再送では「少なくとも一回」と「重複なし」を分ける
ネットワークの再接続時に送信側が同じデータを再送するのは自然な動作です。受信側が保存後の応答を返す前に通信が切れれば、送信側は保存されたか分からず再送します。したがって、配送方式だけを「exactly once」と呼んでも、センサー計測から最終分析テーブルまで重複ゼロと断言できません。どの境界で確認応答を返すか、識別キーで何を同一イベントと見なすか、再送の順序が入れ替わった時にどう扱うかを仕様化します。
重複排除は元イベントIDとバージョンを優先し、同一キーの同一内容なら二重計上しません。同一キーなのに値が違う場合は静かに上書きせず、衝突として隔離し担当者へ通知します。訂正を許すなら、原値、訂正値、理由、操作者、時刻を履歴に残します。期間集計の再計算方法も定めます。締切後に遅着した値が入ると、前日の平均・最大・逸脱件数が変わり得るからです。
センサーがイベントIDを出さない場合は、読み取り時点でゲートウェイが永続的な連番を付けられるか確認します。ゲートウェイ再起動で連番が1に戻るなら、起動IDなどと組み合わせます。センサー値と時刻だけをキーにすると、同じ値が続いた正常な測定を誤って重複とみなす恐れがあります。ここはソフトウェア仕様書に短い一行で済ませず、サンプルデータを使って受入試験を作る部分です。
RFPには製品名より先に「データ契約」を書く
調達依頼書（RFP）では「IoTプラットフォームを導入したい」だけでは、各社が異なる前提で提案します。タグ台帳の試作、故障シナリオ、判定式、責任分界を渡して比較可能にします。まず対象を1ライン・数タグに絞り、次の項目を表として添付します。
- 対象と用途：発注側は設備ID、タグ、単位、工程、ロットとの紐付け、誰が何に使うかを書く。提案側は対応可能範囲と必要な改修を答える。
- 期待イベント：発注側は固定周期か変化時か、稼働カレンダー、予定件数の算出方法を書く。提案側は実際の取得方式と制約を答える。
- 時刻と品質：発注側は時刻の発生源、同期、Bad/Uncertain、推定と手補正の扱いを書く。提案側は保存される項目と伝搬経路を答える。
- 障害と復旧：発注側は通信断・再起動・ディスク満杯・宛先停止の想定時間を書く。提案側はバッファ容量、廃棄順、追いつく時間を答える。
- 受入判定：発注側は暫定・確定完全性、遅延、重複、監査ログの条件を書く。提案側はFAT/SAT手順と証跡の形式を答える。
- 運用責任：発注側はアラート受信者、是正期限、変更承認を書く。提案側は監視項目、保守境界、費用を答える。
「予定件数を何と比べるか」は発注側で合意してから提案を集めます。例えば夜間停止を含めた24時間の分母と、実際の稼働8時間だけの分母では、同じシステムでも完全性が違って見えます。業者に任せきりにすると各社の数字は比較できません。判定式は付属資料にサンプル計算を載せ、実装側が同じ結果を再現できるようにします。
見積はセンサー・配線・ゲートウェイ・通信・保存・ダッシュボード・保守に分けるだけでなく、障害試験の工数とデータ契約の作成工数を明示してもらいます。後者が抜けた低価格提案は、後から「欠測は仕様外」となるリスクがあります。既存設備への接続経路やタグ点数の見積を先に整理したい場合は、PLCデータ収集の4経路を参照してください。本稿の受入条件は、その経路を選んだ後に適用します。
FATで「正常時」より「壊した時」の証跡を取る
試験データの正本を先に作る
FATを始める前に、入力予定をCSVなどの改変しにくい形で凍結し、試験器の設定番号と時刻の基準を記録します。受信側の件数だけを数えても、入力側が予定どおり発生したか分からないからです。固定周期の試験なら、設備IDとタグごとの予定スロット一覧を作ります。変化時通知なら、値の変化順序と送信すべきイベント一覧を作ります。入力の正本、エッジの受領ログ、最終保存先のエクスポートを同じキーで結合できるようにしておくと、消失箇所を境界ごとに特定できます。
試験の途中で人が手動操作を行う場合は、その操作もイベントとして時刻付きで記録します。「切断したはずの時刻」とネットワーク機器が実際に切れた時刻が違うと、予定件数の計算が変わります。時刻同期が切れる試験では、壁時計の表示を正解として照合せず、試験器の単調増加する番号を主軸に件数を突き合わせます。時計が直った後に時刻を再解釈する必要がある場合は、その補正規則を事前に決めます。
合否判定は一つの総合点にしません。例えば「20分の通信断で原イベントは全件残ったが、復旧後の95パーセンタイル遅延が要求を超えた」なら、完全性は合格でも遅延は不合格です。また「全件届いたが一部を二重計上した」なら、配送は成功でも集計は不合格です。障害ごとに機能、完全性、遅延、品質、監査性を別の欄で評価すれば、どの修正が必要かが明確になります。
FAT（工場出荷前受入試験）では、デモ画面にグラフが出るだけでは合格にできません。試験用の入力値と時刻を固定し、ゲートウェイの通信を切り、一定件数を発生させ、復旧後に原記録と保存記録を照合します。意図的な欠測と、遅着して回復した記録を区別できるか確認します。可能ならセンサー入力を模擬する試験器、ゲートウェイ入口のログ、受信側のエクスポートを三点で揃えます。
FATの試験票には、試験ID、前提設定、入力件数、障害開始・終了、期待結果、実測件数、重複件数、品質状態、遅延分布、ログの所在、判定者を記します。「20分切断したが最後にはグラフがつながった」は証跡として弱い。20分間の予定スロットが何件で、そのうち何件がいつ届き、何件が重複除外され、届かなかった件数はいくつか、を出します。
最低限試す故障は、上位ネットワーク断、受信サーバ停止、ゲートウェイ再起動、バッファ上限接近、時計同期失敗、品質Badの入力、同一イベント再送、順序逆転です。装置構成によってはPLC側のキューあふれ、無線リンクの断続、電源瞬断も加えます。試験中に制御へ影響を与えてはいけないので、模擬環境で安全に行う範囲と現場で行う範囲を分けます。
SATでは工場の時刻・電源・交代勤務を含めて確認する
受入後の変更を見越した引き継ぎ資料
引き渡し時には、完成時の設定値だけでなく、どの設定が欠測判定に影響するかを一覧にします。タグの追加、取得周期の変更、センサー交換、ゲートウェイのファームウェア更新、送信先の変更、工場の稼働カレンダーの更新は、いずれも予定件数や遅延の基準を変え得ます。誰が申請し、誰が承認し、変更後にどの試験を再実施するかまで運用手順にします。FAT時のログ形式がソフトウェア更新で変わった時も、照合スクリプトや監査証跡が使えるか再確認します。
予備機へ交換した後にバッファ内の未送信記録をどう扱うかも重要です。故障機のディスクから取り出せるのか、取り出せない場合は欠測区間をどう確定するのかを決めておきます。予備機が同じ設備IDで送信を始めると、古い機器から遅れて届くイベントと新しいイベントのキーが衝突する可能性があります。機器インスタンスの識別子、交換日時、重複排除の規則を引き継ぎ資料に残します。ここまで試して初めて、単発のPoCから継続運用へ移る準備ができます。
SAT（現地受入試験）はFATの再演だけでは足りません。実際のネットワーク分離、制御盤の空間、UPSの有無、夜間停止、シフト引継ぎ、タイと本社の表示時刻が加わります。試験の予定時間を生産と保全部門に共有し、障害注入が許される安全な範囲を決めます。切断試験を本番ラインで実施できない場合は、試験用の経路で行い、本番で実証できなかった範囲を受入記録に残します。
現場の無線品質が時間帯や搬送台車の位置で変わるなら、短いデモだけでは判断できません。少なくとも対象工程の一巡とシフト交代を含む観察期間を決め、欠測アラートが誰に届き、誰が一次切り分けをするかを確認します。設備保全、品質、生産技術、ITの各担当が同じ画面で「センサー故障」「通信遅延」「表示遅延」を区別できるかを見ます。異常のたびにベンダーへログ取得を依頼しないと原因が分からない構成は、運用開始後に長く放置されがちです。
合格値は一律の「99.9%」ではなく、用途と障害シナリオごとに定めます。アラートに使う高温値は速報遅延が短くなければ意味がありません。一方、月次のエネルギー分析は多少遅れても確定完全性を重視できます。重要な品質記録では、欠測そのものを隠さず「この区間は測定不能」と明示できることが要求になる場合があります。RFPで合意した値をSATで検証し、不合格の時は再試験条件と暫定運用を記録します。
稼働後の監視は「欠けた件数」から是正作業へつなぐ
導入後は毎日のダッシュボードに欠測率だけを載せても改善につながりません。対象設備、タグ、開始・終了時刻、予定件数、回復件数、未回復件数、品質Bad件数、最初に異常になった境界を同じチケットにまとめます。担当者はセンサー・制御、OTネットワーク、エッジ、クラウド、アプリのどこを調べるか判断できます。未回復が品質判定に影響した場合のロット保留・追加検査・逸脱承認も業務フローに結び付けます。
週次では、故障原因の件数だけでなく再発回数と回復時間を見ます。バッファ上限警告が増えているのに未欠測だから放置すると、次の長い通信断で消失します。時計同期の失敗も、値が見える間は気付かれにくい。時刻の信頼状態を監視項目に入れます。設定変更時は、サンプリング周期、デッドバンド、キュー長、保持期間の変更が予定件数と判定式にどう影響するか、変更前後で記録します。
ロットとの紐付けを進める工場では、センサーデータだけが揃ってもトレーサビリティは完成しません。材料、工程、設備、検査、出荷の識別子をつなぐ設計はトレーサビリティ構築の費用と進め方で扱っています。本稿の欠測対策は、その連鎖のうち設備・工程条件の記録を信頼できるものにする仕事です。
見積比較では責任分界と「欠けた後の作業」まで比べる
データ欠測対策の提案価格は、機器の単価だけで比べると誤ります。同じゲートウェイを使っても、センサー交換を誰が行うか、PLCのタグ変更を誰が承認するか、ネットワーク障害を誰が調べるか、過去データの再投入を誰が実施するかで運用費は変わります。発注側は障害の六段階について一次窓口と二次対応者を決め、各社に同じ条件で保守費を見積もってもらいます。単に「24時間サポート」と書かれていても、品質部門が必要とする欠測区間の確定やロット影響の抽出まで含むとは限りません。
特に確認したいのは、障害の検知から復旧までの実務です。アラートが出たら誰がログを保存するか。現場が機器を再起動しても、未送信のバッファを保持できるか。交換した機器から旧データを回収できるか。回収できない場合は欠測を確定し、品質部門へどの形式で渡すか。休日の障害では、復旧を急ぐために証跡を消してしまうことがあります。再起動前のログ採取、バッファ残数の記録、障害時刻の共有を短い手順書にして、シフトの担当者が実行できるようにします。
見積依頼には二つの費用シナリオを用意すると比較しやすくなります。一つは通常運用で、タグ追加、月次点検、設定バックアップ、レポート確認を含めます。もう一つは障害対応で、通信断からの再送、破損した記録の隔離、原データとの照合、再集計、監査用の報告を含めます。後者を無償と仮定した提案は、障害が起きて初めて作業範囲の解釈が割れることがあります。費用の大小だけでなく、実施主体と成果物の形で比べます。
将来のライン追加も同じ方式で見積もります。初期の1ラインでは人手で照合できても、10ラインになると毎朝の欠測チェックに専任者が必要かもしれません。自動化するなら、予定件数の生成、遅着後の再照合、チケット発行、日次レポートまでをどこまで標準機能として提供するか確認します。既設のMESや品質システムへロット保留の情報を渡す場合は、連携の責任境界を別行にします。ここを明確にすれば、データ収集基盤の価格だけでなく、品質記録を維持する総費用で比較できます。
小さく導入する時の順序｜一設備の実測から横展開まで
最初の対象は、異常が起きた時に記録の説明が必要で、かつ試験を安全に行える設備を選びます。すべての温度計を同時につなぐより、一つの加熱工程と、その工程に関係する温度・圧力・運転状態・ロット開始終了の少数の信号で始める方が、欠測の原因を追えます。品質部門が使う条件を一つ、現場が使う条件を一つ決め、どちらの判断に何分以内の値が要るかを言葉にします。信号の数を先に増やすと、予定件数の定義と品質状態の解釈が追いつかず、値の山だけが残ります。
最初の観察では既存の測定器や紙記録と並走させ、連続した一工程を通してデータがどう出るかを確認します。計画停止を分母から外す規則、洗浄中の値をどう扱うか、品種切替後にタグの意味が変わらないかを現場と話し合います。ここで作るタグ台帳は単なるアドレス表ではありません。設備ID、センサーの設置場所、単位、正常範囲、計測周期、変化時通知の条件、時計の出所、品質フラグの意味、保守責任者、用途を一行で引けるようにします。後から設備を増やす時、この台帳を複製して差分を確認すれば、同じ誤りを広げずに済みます。
次の段階で通信断と再起動を試し、何件がエッジへ入り、何件が最終保存先まで届いたかを三点照合します。障害を入れる前に正常時の差分がゼロであることを確認します。正常時から件数が合わないまま切断試験をしても、新しい欠測と元からあった設定ミスが混ざります。試験中は制御システムへの書込みを行わず、読取負荷と安全上の制約を設備メーカーと確認します。試験後はバッファ残数が元へ戻ったかまで見ることが必要です。見かけ上は全件届いていても、再送キューが残り続ければ、次の障害で容量を使い切る可能性があります。
横展開の前には、最初の設備と二台目の設備で条件が本当に同じかを比べます。PLCの型式だけでなく、ファームウェア、センサーの精度、ネットワーク経路、装置の停止パターン、電源の保護、保全担当が違うことがあります。テンプレート化してよいのはデータ契約と試験票の枠組みで、期待件数や合格値まで一律にコピーするべきではありません。ラインごとの例外を台帳に書き、全体集計では比較できる指標だけを同じグラフへ載せます。導入順序をこのように刻むと、PoCで見つけた不具合を次の設備へ持ち込む前に修正できます。
証跡を残す期間と訂正方法を品質部門と決める
欠測を発見した後の運用では、いつまで原データを残すかが問題になります。ダッシュボードに表示する集計値だけを保存し、元の受信記録を短期間で消してしまうと、後日の監査で「本当に欠けたのか、後から届いたのか」を再確認できません。一方、全タグの高頻度データを無期限に保存する構成は費用が大きくなります。対象製品の品質記録として必要な期間、社内の監査要件、顧客との契約、分析目的の保管期間を分け、原記録と集計結果の保存先を設計します。法令や顧客仕様の保存年限は業界と製品によって異なるため、この場で一律の年数は置きません。
後から届いた記録を受け入れる締切も決めます。例えば日次集計を翌朝に確定する運用なら、その前に届いた記録を自動で再計算し、確定後は訂正申請を要する方式が考えられます。ただし、この締切は業務例であり、品質判定に使う工程ではもっと厳しい手順が必要かもしれません。確定済みの値を変える時は、元の値を消さず、変更前後、変更理由、承認者、再集計した帳票を一組で保存します。集計結果だけ差し替えると、当時のアラート画面や顧客へ出した報告と矛盾します。報告の版を付け、どの版でどの判断をしたか追えるようにします。
品質フラグには「通信断」「センサー故障」「測定範囲外」「時計同期不明」「補間値」「手補正」など、業務で区別したい理由を必要な粒度で持たせます。ただし製品固有の品質コードをそのまま全社共通の意味に置き換えないようにします。PLC、OPC UAサーバ、ゲートウェイ、ヒストリアン、MESで同じ言葉が異なる意味を持つことがあります。変換表を作り、元コードも保持し、マッピング不能な値は勝手にGood扱いしません。受入試験には未知のコードを一件入れ、保存と通知がどうなるか確認します。
障害レポートは責任追及の資料だけでなく、次の設計変更の入力です。欠測が多かったタグを無条件に高頻度へ変えるのではなく、原信号が本当に必要だったか、検知に使う時間幅は適切か、バッファの容量や送信帯域が不足していたかを見直します。毎月同じ数分の欠測が起こるなら、定期的な設備停止やネットワーク保守が分母へ正しく反映されていない可能性もあります。運用データをもとに判定式そのものを変更する時は、過去期間へ新しい式を遡及適用するかどうかを明示し、前後の数字を無言で混ぜないようにします。
日々の照合を担当者の経験だけに頼らないため、朝の確認手順も決めておきます。前日の予定件数を稼働実績から生成し、到着済みの一意記録と突き合わせ、欠けた区間を設備ごとに一覧化します。その時点でバッファに残る件数と最終保存先に届いた件数を分け、遅着を待つ期限を表示します。期限前の値は暫定、期限後も届かない値は未回復として扱い、品質判断に影響する区間だけを優先して現場へ連絡します。再送が終わったら同じ条件で照合をやり直し、前回との差分と判定を保存します。これなら担当者が交代しても、昨日は欠測と報告したのに今日は何の説明もなく消えている、という事態を避けられます。
照合処理自体が止まった時にも気付けるようにします。記録の欠測アラートだけでは、照合ジョブが失敗して何も数えなかった日を正常と誤認するからです。最終実行時刻、対象設備数、処理した予定件数、失敗したタグ数を監視し、実行できなかった日は日次報告に明示します。復旧後はその日を再処理し、当時の稼働カレンダーとタグ設定の版を使って同じ判定式を再現します。現在の設定で過去を数え直すと、計画停止や取得周期の変更が反映されず、数字だけが変わる恐れがあります。必要な設定履歴を原記録と一緒に残すことが、後から説明できる欠測管理につながります。
FAQ｜工場センサーデータ欠測対策の導入でよくある質問
センサーデータが欠けたら、補間して埋めればよいですか？
用途によります。温度傾向の可視化では補間が有用な場合がありますが、品質保証やアラームの証跡で補間値を実測値として扱うべきではありません。元の欠測区間を保持し、補間値には「推定」の品質フラグと計算方法を付けます。表示用の線と監査用の原記録を分けて管理します。
MQTTのQoSを上げれば欠測はなくなりますか？
いいえ。QoSは特定の通信区間の配送動作を定めますが、センサーで測定できなかった値、ゲートウェイに入る前に落ちた値、受信後に集計から漏れた値まで保証しません。必要な区間ごとに確認応答、永続化、再送、重複排除、照合を試験します。MQTTの機能を比較する際はOASIS MQTT 5.0仕様を参照し、製品の実装範囲は別途確認します。
欠測率の目標は何%にすればよいですか？
一律の値は置けません。記録周期、設備の稼働カレンダー、許される復旧時間、品質判定への影響で変わります。まず一つの工程の基準値を測り、速報と確定を分け、重大な欠測区間を件数とは別に扱います。平均99.9%でも、重要な10分間が丸ごと無ければ業務上は不合格になり得ます。
RFPとFAT・SATは小さなPoCにも必要ですか？
数十ページの文書は不要ですが、期待件数の式、タイムスタンプの由来、通信断試験、重複判定、合否条件を一枚の試験票にしておく価値があります。PoCでこの条件を検証すれば、横展開の見積を比較しやすくなります。省いた場合は「グラフは出たが欠測の責任範囲は未定」という結果が残ります。
まとめ｜見える値ではなく、説明できる記録を受け入れる
工場センサーデータ欠測対策は、センサーやクラウドを選ぶ前後に「期待する記録」の定義を置くことで実務に変わります。固定周期と変化時記録を分け、計測時刻・受信時刻・品質・イベントIDを保存し、暫定完全性と確定完全性を別々に測る。バッファ容量だけでなく復旧帯域と重複排除を設計する。RFPの判定式をFAT・SATで同じ形の証跡として確認する。この順で進めれば、数字が出ているだけの監視から、欠けた理由と影響範囲を説明できる運用へ移れます。
タイ工場の既設設備を対象に、タグ台帳や通信断の試験条件から検討したい場合は、対象ラインと使いたい記録の用途を添えてTOMAS TECHへご相談ください。構成や製品が未確定の段階でも、受入条件の整理から一緒に進められます。
