設備ログを見ても、原因の順番が見えません。
製造現場では、アラーム履歴や測定データが残っていても、時刻がずれているだけで解析が一気に難しくなります。
特にPLC、HMI、データ収集PC、上位サーバが別々の時計で動いている設備では、同じ異常でも記録時刻に差が出ます。
この差を放置すると、異常解析、品質トレーサビリティ、設備稼働分析の信頼性が下がります。
本記事では、タイムスタンプの意味、設備データでの使い方、NTPによる時刻同期、データ収集時の注意点を解説します。
- 1. タイムスタンプとは：データに時刻を付ける仕組み
- 2. 設備データで時刻が付く場所：どこで記録するか
- 3. 時刻同期とは：設備ごとの時計を合わせる考え方
- 4. 異常解析でタイムスタンプが重要な理由
- 5. データ収集時の注意点：時刻の意味を揃える
- 6. 時刻同期の実装：現場で決めるべき設計項目
- 7. よくある失敗：時刻が合っているように見える落とし穴
- 8. まとめ
1. タイムスタンプとは：データに時刻を付ける仕組み
タイムスタンプとは、データやイベントに付ける時刻情報のことです。
設備データでは、センサ値、アラーム、操作履歴、通信ログなどに時刻を持たせます。
単に「値を保存する」だけでは、後から現象の順番を追うことができません。
値に時刻を付けることで、設備の状態変化を時系列で確認できます。
発生時刻：現象が実際に起きた時刻
発生時刻は、入力変化や異常発生などの現象が起きた時刻です。
設備解析では、この発生時刻が最も重要になります。
例えば、モータ過負荷の前に圧力上昇が起きたのか、過負荷後に圧力が上がったのかで原因の見方は変わります。
この順番を判断するには、イベントごとの発生時刻が必要です。
PLC側で発生時刻を持てる場合は、上位PCで受け取る時刻よりも現象に近い時刻になります。
記録時刻：データベースへ保存された時刻
記録時刻は、データがサーバやデータベースへ保存された時刻です。
現象が起きた瞬間ではなく、収集処理が完了した時刻になる場合があります。
通信が遅れたり、バッファに一時保存されたりすると、発生時刻と記録時刻に差が出ます。
設備ログを見るときは、どの時刻が表示されているのかを確認する必要があります。
「表示されている時刻＝発生時刻」と思い込むと、原因と結果を逆に判断することがあります。
タイムスタンプがないログの弱点
時刻がないログは、単なる記録の一覧になってしまいます。
どの現象が先に起きたか、どの設備と連動していたかを判断しにくくなります。
特に、複数設備が連動するラインでは、時刻のないログは解析に使いにくくなります。
設備Aの停止、搬送機の滞留、検査機のNG判定を関連付けるには、時刻軸が必要です。
タイムスタンプは、設備データを「後から読める情報」に変えるための基本要素です。
さらに、担当者が変わっても同じログを同じ順序で読めるようになります。
現場の記憶に頼らず、設備状態を客観的に説明するための共通言語と考えると分かりやすいです。
2. 設備データで時刻が付く場所：どこで記録するか
設備データのタイムスタンプは、一箇所だけで付くわけではありません。
PLC、HMI、SCADA、データベース、クラウドなど、複数の層で時刻が付きます。
どの層の時刻を採用するかで、解析結果の見え方が変わります。
そのため、データ収集設計では「誰が時刻を付けるか」を最初に決めることが重要です。
センサ・入力信号：最も現象に近い場所
センサやスイッチ入力は、現象に最も近いデータ発生源です。
ただし、単純なデジタル入力では、入力信号そのものに時刻情報はありません。
I/O信号はON/OFFや電圧値として扱われ、時刻は制御機器側で付けるのが一般的です。
高速な異常解析では、入力更新周期やプログラム処理周期も無視できません。
特に短時間だけ発生するチャタリングやパルスは、どの周期で読んだかが重要になります。
PLC・制御装置：工程の判断時刻を持つ層
PLCは、入力を読み取り、プログラムを実行し、出力を更新します。
そのため、設備の制御判断に近い時刻を扱うことができます。
例えば、異常フラグが立った時刻、運転モードが変わった時刻、ワーク通過を検出した時刻などです。
ただし、PLC内の時計がずれていると、上位側と時刻が一致しません。
A/D変換で取り込むアナログ値も、サンプリング周期と時刻の関係を合わせて考える必要があります。
HMI・SCADA・上位サーバ：見える化と保存の層
HMIやSCADAは、設備状態を画面に表示し、アラームや履歴を保存します。
この層で時刻を付けると、画面表示や帳票化には扱いやすくなります。
一方で、通信遅延や収集周期の影響を受けるため、発生源の時刻とはずれることがあります。
設備データ連携では、OPC UAのようにデータ値と時刻を一緒に扱える仕組みが重要になります。
上位サーバで統合するときは、設備ごとの時刻の意味を揃えておく必要があります。
画面表示用の時刻と保存用の時刻を分ける場合は、仕様書の項目名も分けます。
例えば、表示時刻、発生時刻、受信時刻を同じ「時刻」という列名にしないことが大切です。
| 時刻を付ける場所 | 主な用途 | 注意点 |
|---|---|---|
| PLC | 異常発生・工程判定の記録 | PLC時計の同期が必要です |
| HMI・SCADA | 画面表示・アラーム履歴 | 通信遅延の影響を受けます |
| データベース | 長期保存・分析・帳票化 | 保存時刻と発生時刻を区別します |
3. 時刻同期とは：設備ごとの時計を合わせる考え方
時刻同期とは、複数の機器の時計を同じ基準に合わせることです。
設備データでは、1台の時計だけが正しくても十分ではありません。
PLC、表示器、産業用PC、サーバ、ネットワーク機器の時計が近い状態で揃っている必要があります。
これにより、複数設備のログを横並びで見ても、時刻の前後関係を比較できます。
NTP：ネットワーク越しに時計を合わせる仕組み
NTPは、Network Time Protocolの略で、ネットワーク上の機器の時刻を同期するためのプロトコルです。
NTPv4はRFC 5905で定義されており、分散したコンピュータ時計の同期に広く使われます。
設備ネットワークでは、工場内のタイムサーバを基準にしてPLCやPCを同期させる構成がよく使われます。
IANAのポート番号登録では、NTPはポート123に割り当てられています。
実務上は、機器がNTPクライアント機能を持つか、時刻同期の設定画面があるかを確認します。
NTPサーバ名で設定する機器もあれば、IPアドレスで直接指定する機器もあります。
DNSを使えない設備ネットワークでは、名前解決に頼らずIPアドレスで指定する方が安定する場合があります。
階層構成：外部時刻と工場内時刻の分離
工場設備では、インターネット上の時刻サーバへ直接つなぐ構成は避けたい場合があります。
そのため、社内または工場内に時刻基準サーバを置く設計が現実的です。
上位の時刻サーバが外部基準に同期し、設備側は工場内サーバだけを見る構成にします。
この構成なら、設備ネットワークの閉域性を保ちながら時刻を揃えやすくなります。
フィールドバスや産業用Ethernetのネットワーク設計とも合わせて検討します。
精度の考え方：必要な細かさは用途で変わる
時刻同期では、必ずしもすべての設備で同じ精度が必要とは限りません。
日報や稼働率の集計なら秒単位で十分な場合があります。
一方で、高速搬送、検査トリガ、複数軸の同期解析では、より細かい時刻精度が必要になります。
重要なのは、必要以上に高精度を狙うことではありません。
目的に対して十分な時刻精度を決め、それを設備全体で維持することです。
例えば、日単位の生産実績では秒未満の精度は不要な場合があります。
一方で、搬送トラブルや検査トリガの解析では、秒単位では粗すぎることがあります。
まず解析したい現象の時間幅を決め、その時間幅より十分細かい粒度で時刻を残します。
4. 異常解析でタイムスタンプが重要な理由
設備異常の解析では、何が起きたかよりも、何が先に起きたかが重要です。
同じアラームでも、発生順序が変わると原因の見立ても変わります。
タイムスタンプが揃っていれば、複数設備のログを一本の時系列として読めます。
逆に時計がずれていると、原因と結果を逆に見てしまう危険があります。
異常発生順序：原因と結果を切り分ける
設備停止時には、複数のアラームが短時間に連続して出ることがあります。
最初に出たアラームが原因に近く、後から出たアラームは結果として残ることも多いです。
ただし、ログの時刻がずれていると、この順番が崩れて見えます。
例えば、サーボ異常、ワーク未到着、非常停止が同じ分に記録されると、判断が難しくなります。
イベント駆動のログでは、イベント発生順序を残す設計が特に重要です。
ミリ秒単位の順序までは不要な設備でも、最初の異常を見失わない粒度は必要です。
発生順序が分かるだけで、調査対象をセンサ、機械、通信、操作のどこに絞るか判断しやすくなります。
設備ログと品質データ：不良発生の前後を追う
品質不良の解析では、測定値、設備条件、アラーム履歴を組み合わせて確認します。
そのとき、時刻が揃っていないと、不良品が通過した瞬間の設備状態を特定しにくくなります。
温度、圧力、電流、速度、検査値などは、時刻とセットで保存して初めて意味を持ちます。
ワークIDやロット番号があっても、時刻が不正確なら前後関係の確認に手間がかかります。
製造業KPIを作る場合も、時刻のそろったデータが前提になります。
アラームの多発：代表アラームを見極める
設備停止では、ひとつの原因から多数のアラームが派生することがあります。
搬送停止により、後段のワーク未到着、検査待ち、タイムアウトが連鎖する例です。
このとき、最初に発生した代表アラームを特定できると、解析時間を短縮できます。
アラーム発生時刻が粗い、または機器ごとにずれていると、代表アラームの判定が難しくなります。
タイムスタンプは、アラームを単なる一覧から原因解析の材料へ変える役割を持ちます。
5. データ収集時の注意点：時刻の意味を揃える
設備データ収集では、データの値だけでなく時刻の意味を揃える必要があります。
同じ「時刻」でも、発生時刻、読取時刻、受信時刻、保存時刻は別物です。
この違いを曖昧にしたまま分析すると、グラフや帳票がもっともらしく見えても判断を誤ります。
データ収集仕様書には、時刻の発生源と保存ルールを明記しておきましょう。
発生源時刻と収集時刻：どちらを使うか
発生源時刻は、PLCやデバイス側で現象に近い時点で付ける時刻です。
収集時刻は、データ収集ソフトやサーバがデータを受け取った時刻です。
通信周期が短く安定していれば差は小さく見えますが、異常時ほど差が広がることがあります。
設備解析では、可能な限り発生源に近い時刻を残す設計が有利です。
Modbusのようなポーリング型通信では、読みに行った周期も時刻解釈に影響します。
バッファリングと通信遅延：後から届くデータ
設備側で一時的にデータをため、後からまとめて送る構成があります。
この場合、サーバ受信時刻だけを使うと、すべてのデータが同じ時刻に見えることがあります。
通信断の復旧後に過去データを送る場合も、受信時刻だけでは実際の発生順序を表せません。
そのため、バッファ内の各データに発生時刻を持たせる設計が重要です。
MQTTでクラウドへ送る場合も、送信時刻と発生時刻を分けて考える必要があります。
時系列データベース：時刻を主軸に保存する
設備データの蓄積では、時系列データベースが使われることがあります。
時系列データベースでは、値、時刻、タグ情報を組み合わせて保存します。
タグ情報には、設備名、ライン名、測定項目、単位、ロットなどを持たせます。
時刻の粒度やタイムゾーンが統一されていないと、後から集計するときに不具合が出ます。
データベースへ入れる前に、時刻形式とタグ命名を標準化しておくことが大切です。
設備名だけでなく、データの発生源、取得周期、単位も合わせて保存すると再利用しやすくなります。
同じ温度データでも、炉内温度、排気温度、ワーク表面温度では意味が異なります。
時刻とタグの設計が揃うほど、後から検索、集計、異常検知に使いやすいデータになります。
関連記事
6. 時刻同期の実装：現場で決めるべき設計項目
時刻同期は、単にNTPを有効にすれば終わりではありません。
どの機器を基準にするか、通信できないときにどう扱うか、ずれをどう監視するかを決めます。
設備立上げ時だけ合わせても、長期運用では時計が少しずつずれることがあります。
保全項目として、時刻同期の確認を組み込むことが重要です。
タイムサーバ：工場内の基準時計を決める
最初に決めるべき項目は、工場内の基準時計です。
基準が複数あると、設備ごとに違う時刻へ同期してしまう可能性があります。
社内ネットワークのNTPサーバ、専用タイムサーバ、上位サーバのどれを使うかを明確にします。
重要設備では、基準サーバの冗長化も検討します。
ただし、冗長化するときも優先順位と同期元を決めておく必要があります。
PLC・HMI・PC：設定場所を一覧化する
現場では、どの機器がNTPに対応しているかがメーカーや機種で異なります。
PLC本体、通信ユニット、HMI、産業用PC、データロガーで設定場所が分かれることもあります。
設定項目には、NTPサーバアドレス、同期周期、タイムゾーン、手動補正の可否などがあります。
設備ごとに設定画面が違うため、立上げ時のチェックリスト化が有効です。
複数のネットワークをまたぐ場合は、EtherNet/IPなどの制御通信と管理通信の分離も確認します。
ずれ監視：時刻同期も設備状態として扱う
時刻同期は、一度設定すれば永遠に正しいとは限りません。
ネットワーク断、NTPサーバ停止、設定変更、電池劣化などで時計がずれることがあります。
そのため、主要機器の時刻ずれを監視し、一定以上ずれたらアラームを出す設計が有効です。
時刻ずれアラームは、生産停止に直結しないため軽視されがちです。
しかし、後日の異常解析や品質保証では大きな影響を与えます。
監視方法としては、基準サーバとの時刻差、最後に同期できた時刻、同期失敗回数を確認します。
保全画面に同期状態を表示すると、トラブル発生前に異常へ気づきやすくなります。
7. よくある失敗：時刻が合っているように見える落とし穴
タイムスタンプのトラブルは、設備が動いている間は気づきにくいものです。
問題が表面化するのは、異常解析やデータ分析を始めた後になることが多いです。
よくある失敗を事前に押さえておくと、データ収集システムの手戻りを減らせます。
特に、タイムゾーン、手動補正、保存形式、時計の基準は最初に決めておきましょう。
タイムゾーン混在：日本時間とUTCを区別する
設備データでは、日本時間で表示したい場面と、UTCで保存したい場面があります。
表示は日本時間、内部保存はUTCという設計も珍しくありません。
問題は、どちらの時刻か分からない状態でデータが混在することです。
クラウド、データベース、CSV出力、BIツールで時刻がずれる原因になります。
時刻項目には、タイムゾーンの扱いを明記し、表示時に変換するルールを決めます。
CSVへ出力するときも、列名にJSTやUTCの意味を含めると誤解を減らせます。
月をまたぐ長期分析では、タイムゾーンの扱いが後から大きな手戻りになることがあります。
手動時刻合わせ：担当者依存にしない
現場では、時計がずれたら手で直す運用になっている設備もあります。
一時的な対処としては有効ですが、長期運用では担当者依存になります。
手動で合わせると、誰がいつ何に合わせたのかが記録されにくくなります。
また、手動補正の瞬間にログ時刻が飛んだり戻ったりすることがあります。
重要な設備データでは、自動同期と補正履歴の記録を基本にする方が安全です。
設備メーカーへ確認するときは、時刻同期の方式、補正周期、ログへの反映方法を具体的に聞きます。
時刻補正の前後でログが飛ぶ場合は、補正イベントそのものも履歴に残します。
これにより、後からグラフの不自然な段差や時刻の巻き戻りを説明できます。
手動運用を完全に無くせない場合でも、作業記録とセットで管理することが大切です。
関連記事
8. まとめ
タイムスタンプとは、設備データやイベントに時刻を付ける仕組みです。
設備ログ、アラーム履歴、品質データ、稼働データは、時刻とセットで残して初めて解析しやすくなります。
重要なのは、発生時刻、収集時刻、保存時刻を混同しないことです。
NTPによる時刻同期を使えば、PLC、HMI、PC、サーバの時計を同じ基準に近づけられます。
ただし、NTPを有効にするだけでは十分ではありません。
基準となるタイムサーバ、同期対象機器、タイムゾーン、ずれ監視、補正履歴まで含めて設計する必要があります。
エッジ処理で現場側にデータを一時保存する場合も、発生時刻を失わない設計が重要です。
設備データ活用の第一歩は、正しい値を集めることだけではありません。
その値が「いつ」の値なのかを、後から確実に説明できる状態にすることです。
現場改善や設備保全でデータを使うほど、タイムスタンプの設計品質が分析結果の信頼性を左右します。
まずは主要設備の時計がどの基準に同期しているかを確認するところから始めましょう。
それだけでも、ログ解析の前提が大きく改善します。
