設備Aの停止ログより先に、設備Bの「A停止受信」が記録されている。 順番が逆に見えても、その場で通信や制御の異常と決めつける前に、二つのことを確認します。その時刻を付けたのはどの機器か、そして、その時刻は何の時刻か。
時計をそろえることと、物理的な出来事の前後を確定することは、別の確認です。 時計を合わせても、検出の周期や通信にかかった時間は消えません。
この記事では、すでに保存されているログを並べて比較するときの整理方法を扱います。 稼働中のPLCやサーバーの時刻設定をその場で変更する手順ではありません。
時刻の列ごとに「誰が何に付けたか」を調べる
同じCSVに並んでいても、ある列は設備が値を更新した時刻、別の列は収集サーバーが受信した時刻かもしれません。 受信側の時計が合っていても、通信待ちやバッファに滞留した時間までなくなるわけではありません。
最初にやることは、1行だけ取り出して列ごとに意味を書き出すことです。 次の表は、その整理のために本記事で提案する時計の対応表です。 実際に存在しない項目は補わず、「未取得」「仕様確認待ち」と書いて残します。
| 対象の列 | 時刻を付ける機器 | 意味 | 比較前に確認すること |
|---|---|---|---|
| 設備のイベント時刻 | PLC・機器など | イベント検出・値更新など | 検出条件、時計、分解能 |
| 収集時刻 | ゲートウェイ・収集PCなど | 読取り・受信など | 通信周期、遅延、再送 |
| データベース登録時刻 | 保存処理をするサーバー | DBへ書き込んだ時刻など | キュー、まとめ書き |
| 画面の表示時刻 | HMI・閲覧画面など | 表示更新・変換後の時刻など | 元列、タイムゾーン、集計 |
意味を埋めるときは、「どこで確認したか」も一緒に残します。仕様書の章番号、設定画面の名称、聞き取りの相手と日付のいずれかです。 推測で埋めた欄は、あとから見分けられなくなります。
例えばOPC UAでは、SourceTimestampとServerTimestampが別の意味を持ちます。 前者はデータ源が値へ付けた時刻で、UTCで表され、他のサーバーを経由しても変更されません。 後者はサーバーが値を受信した、または正確だと把握した時刻を表します。 ServerTimestampを、常に物理現象の発生時刻や自社DBへの登録時刻と同一視しないでください。 これはOPC UAの仕様上の区別であり、手元の接続構成やDBの登録時刻が同じ性質を持つとは限りません。
タイムゾーンのずれと時計のずれを分ける
表示が違うだけなのか、時計そのものが進んでいる・遅れているのかを分けます。
例えば 2026-10-16T03:00:00Z と 2026-10-16T12:00:00+09:00 は、表記が違うだけで同じ瞬間を指します。
ここへさらに9時間を加えると、二重変換になります。
元ファイルの時刻文字列、タイムゾーン指定、表示ソフトの変換設定を確認したうえで、比較に使う時刻表現を決めます。 決めたあとは、原ファイルの時刻文字列をそのまま残した列を必ず持っておきます。 タイムゾーンの記載がない時刻は、保存機器の設定や仕様を確認するまで、UTCか日本時間かを推測で決めません。
時刻同期の設定がある場合も、「同期している設定だから正しい」とは言えません。 同期先、同期できていた期間、エラー履歴、確認できる精度を、それぞれ記録として残します。 RFC 5424 §7.1は、syslogでタイムゾーンを把握しているか、同期しているか、どの程度の精度かを分けて表す仕組みを定義しています。 これはsyslogの項目であり、すべてのPLCログに同じ情報が付くという意味ではありません。
補正する場合は、原時刻と根拠を残す
時計のずれを補正するなら、元の時刻を上書きせず、比較用の列を追加します。 「いつ、どの時計に対して、どれだけずれていたか」を補正の根拠として書き添えてください。
説明用に、PLCの時計が基準時計より2.000秒進んでおり、そのずれを対象区間に適用できると確認した場合を仮定します。 比較用時刻は「PLCの原時刻−2.000秒」です。
| 記録 | 原時刻 | 比較用時刻 | 補正根拠 |
|---|---|---|---|
| PLC側の記録 | 12:00:02.100 | 12:00:00.100 | 対象区間で+2.000秒と確認 |
| 収集側の記録 | 12:00:00.150 | 12:00:00.150 | 基準時計と対応を確認 |
この2.000秒は説明用の仮定で、実設備の測定値ではありません。 一度確認したずれを、数日前のログ全体へそのまま当てはめられるとは限りません。 再起動、手動の時刻変更、同期状態の変化があれば、そこを境に適用できる区間を分けます。 確認できない区間は補正値を空欄にして、未確認のまま扱います。「この区間は補正量未確認」と書いた行を残しておけば、後から読む人が誤って補正済みと解釈せずに済みます。
時間差が小さいときは、前後を断定しない
補正後に50msの差があっても、実際の出来事が50ms離れていたとは限りません。 時計の誤差に加えて、信号を検出する周期、通信、記録のしかたが関わるためです。
まず時計だけの例として、前節の二つの比較用時刻に、それぞれ最大±40msのずれが残ると仮定します。 PLC側の時刻は12:00:00.060〜.140、収集側は12:00:00.110〜.190の範囲になります。 この二つの範囲は12:00:00.110〜.140で重なるため、時刻の値だけでは記録時点の前後を確定できません。 ±40msは説明用の上限で、一般的な同期精度や統計的な信頼区間ではありません。
物理的な出来事の順序まで判断するには、さらに、どの状態変化を記録したのかをそろえ、検出・転送・保存の遅れも確認します。 同じ機器の中で付く連番や工程番号は補助情報になりますが、リセット条件と採番の仕様が分からないうちは、別機器の番号同士を直接比較しません。 判定できなかった区間は、「順序未確定」と結論に書きます。どちらか一方を選んで書くと、後続の調査がその前提に引きずられます。
同期設定を変える前後で、比較を区切る
時刻を合わせる操作は、過去ログの誤差を自動的に直すものではありません。 変更を検討するときは、設備・IT担当者が対応機能と運転への影響を確認し、作業の承認、変更前後の状態、戻し方を決めます。 時刻が飛ぶ・戻る可能性も確認し、その境界を解析側へ引き継ぎます。境界をまたいだ区間は、ひと続きの時系列として扱いません。
比較表には、少なくとも次の項目を1行ずつ対応させます。原ファイル、行やイベントの識別子、原時刻、比較用時刻、補正量、適用区間、根拠、未確認事項です。 時刻だけで結合して別のイベントを同一視したり、時計が合わない行を黙って削除したりしないようにします。
PLC・SCADA・ヒストリアンの役割を分けたうえで、どの層が時刻と品質情報を保持するかを決めます。 順序が判定できない区間が残ったら、製造データの収集設計へ戻り、必要な観測項目と時間の粒度を担当者へ伝えてください。