故障履歴の時刻が合わない｜発生・受信・登録を分けて原因を追う

設備の停止記録より後に、原因らしい警報が届いている。日報と監視履歴を並べると順序が逆に見える。ここで「停止してから警報が出た」と結論づける前に、各欄の日時が何を示しているかを確かめたい。現場で起きた時刻と、システムに届いた時刻、担当者が入力した時刻は一致するとは限らない。

本稿は、設備の状態履歴と保全担当者の記録を突き合わせる際の整理を扱う。画面の時系列を整えるために元の日時を上書きせず、何が分かり、何が不明なのかを残すことが要点である。

「日時」という列名だけでは比較できない

最初に、履歴の各時刻が作られる場所を確認する。センサ、PLC、収集サーバ、保全管理システム、入力端末では、別々の処理や時計が関わり得る。表示形式が同じでも、意味まで同じとは限らない。

例えば、説明用の架空例として、設備P-201が10時02分に停止し、通信復旧後の10時10分に状態履歴が届き、担当者が10時30分に報告を登録したとする。10時30分を停止時刻として扱うと、実際の経過とずれる。逆に、登録時刻を10時02分へ書き換えると、誰がいつ報告したかが失われる。

これは記録設計のための編集上の整理例である。全ての項目を手入力で増やすという意味ではない。自動取得する項目と現場が補う項目を決め、同じ名前の欄へ異なる時刻を入れないようにする。

自動収集の時刻にも、複数の意味がある

OPC UAの公式仕様では、値へデータ源が付与するSourceTimestampと、サーバ側のServerTimestampを区別している。SourceTimestampはUTCとされ、値または状態コードの最後の変化を示すべきものとして説明されている。他のOPC UAサーバから値を受け取る場合、元のSourceTimestampは変更せず引き継ぐ規定がある。[1]

一方、ServerTimestampは、サーバが値を受信した時刻、またはその値が正しいと把握した時刻を表す。値が変わらなくても更新される場合がある。[2] したがって、サーバ時刻の更新を、そのまま設備の状態変化が起きた証拠として扱えない。

ここで参照したのはOPC UAの値の時刻に関する仕様である。全ての設備ログがこの意味で実装されているとは限らず、業務上の故障発生時刻を自動で確定する仕組みでもない。実際の収集経路と項目定義を確認する必要がある。

復旧後に届いた履歴を、到着順だけで並べない

前述の架空例では、10時10分に届いた記録が10時02分の停止を示している。通信断の間に保存された履歴が、復旧後にまとめて届いたという条件なら、到着時刻だけで現場の順序を再現することはできない。

調査では、元の記録が持つ時刻と受信時刻を並べ、その差を調べる。同時に、どの装置が時刻を付けたか、途中の変換で元の日時が残ったか、同じ記録が再送されていないかを確認する。「古い時刻のデータ」を一律に捨てる前に、遅着した履歴と重複の区別が必要になる。

ただし、二つの時刻の差だけで通信遅延を測定できたとは言えない。別の時計で付けた時刻なら、時計のずれも候補に残る。元の値、単位、設備番号、記録の識別子を一緒に保ち、調査の根拠を一つの日時列へ縮めないことが重要だ。

時間帯と時計のずれを、別々に確認する

日時を突き合わせる際は、日本時間表示なのか、UTCで保存された値なのかを確認する。例えば、同じ瞬間の09時00分JSTと00時00分UTCを、異なる出来事として並べない。変換規則を確認せず、見た目を合わせるために一律で時間を足すことも避けたい。

その上で、装置やサーバの時計がどのように管理されているかを見る。時刻同期の設定があることと、対象期間に正しく同期していたことは別である。確認できる同期状態、時計の修正、端末交換の履歴を、問題が起きた期間と照合する。

秒まで同じ形式で表示されていても、元の記録が分単位なら、秒単位の前後関係は確定できない。表示桁数と実際に分かる精度を分け、不明な秒をゼロで補った記録を精密な観測として扱わない。

停止時間を計算する前に、開始と終了を定義する

停止の記録を集計するなら、どの状態を開始と終了にするかを先に決める。設備停止、修理着手、修理完了、試運転完了、生産再開は、それぞれ別の場面である。作業報告の完了時刻を、設備が再び使用可能になった時刻と取り違えない。

架空例として、10時02分に停止し、10時20分に修理へ着手、11時00分に作業を終え、11時15分に生産が再開した場合を考える。停止から生産再開までなら73分、修理着手から作業終了までなら40分である。どちらも計算できるが、同じ意味の時間ではない。この数値は説明用であり、実設備の実績や標準時間ではない。

現場と集計担当で開始・終了の意味をそろえ、集計表には対象範囲を併記する。途中の待機を含むか、操業予定のない時間をどう扱うかなども、業務側で決める事項である。本稿は特定の指標や規格への適合を示すものではない。

分からない発生時刻を、登録時刻で確定させない

巡回で故障を発見した場合、発見時刻は分かっても、発生時刻が分からないことがある。「最後に正常を確認した時刻」と「異常を発見した時刻」が分かるなら、その二つを残す。登録システムが日時の入力を必須にしていても、仮の入力値を確定した発生時刻として集計しない運用が必要である。

記録には、時刻の根拠と確からしさを添える。自動ログで確認、担当者が目視、後日の聞き取り、推定、未確認などを区別すれば、原因分析で同じ重みの証拠として扱わずに済む。発生時刻が未確定の事例は、停止時間の集計でもその制約を引き継ぎ、確定した時間と混ぜて平均しない。後から根拠が見つかった場合は、訂正前の値、訂正理由、更新者を追えるようにする。

次の担当者が、同じ時系列を再現できる状態にする

まず一件の停止を選び、現場記録、監視ログ、作業報告を同じ設備番号で結ぶ。各時刻の意味、付与した場所、時間帯、確認できない範囲を並べてから、順序を検討する。日時が一致しないこと自体を、どちらかの記録の誤りと決めつけない。

通知の頻発や配送との関係は、アラームの発生・復帰・再通知を分ける記事でも扱っている。設備台帳と履歴を結ぶ際には、測定値だけでなく、その値がいつの何を表すかを一緒に残す。その積み重ねが、停止原因と対応の経過を比較できる記録につながる。

参考文献

[1] OPC Foundation『OPC UA Part 4: Services』v1.05.07、7.11.3 SourceTimestamp。値の時刻の意味、UTC、サーバ間での引継ぎ。2026年11月8日確認。公式仕様本文

[2] OPC Foundation『OPC UA Part 4: Services』v1.05.07、7.11.4 ServerTimestamp。受信または正しいと把握した時刻、値が変わらない場合の例。2026年11月8日確認。公式仕様本文