デジタルツインの同期を「高頻度にすればよい」と考えると、ログの再現性や安全境界を見落としやすい点が気になります。
結論：同期周期は一つに統一しない
ロボットのデジタルツインでは、すべてのデータを同じ周期で同期するのではなく、データクラスごとに同期粒度、更新トリガー、許容遅延、欠損時の動作を定義するのが基本です。
関節位置・速度・トルク、ベース姿勢・速度、インターロックなど、制御や安全に直結する状態は、実機の制御・計測周期または状態変化イベントに近い粒度で扱います。環境・シーン、ロボット形状、質量や摩擦などのモデルパラメータ、劣化・保全情報は、状態変更、再キャリブレーション、保全イベント、モデル再同定などを契機に更新します。運用ログは最新値への上書きではなく、後から時系列を再現できる記録として保存します。
つまり、問うべきなのは「何Hzで同期するか」だけではありません。何の時刻を表すデータか、どの値を正当な実機状態とみなすか、遅延や欠損が起きたときどう扱うかを、データクラス別の同期契約として明文化することが重要です。
なぜ同期粒度が重要か
ISO 23247は、製造要素、デジタルツイン、サービスや利用者の関係を整理する参照枠組みを示しています。一方で、すべてのロボットやデータに共通する同期周期を規定しているわけではありません。ロボットの制御周期、通信構成、シミュレータ、利用目的によって適切な粒度は変わります。
また、文献によってデジタルモデル、デジタルシャドウ、デジタルツインの区分も異なります。一般には、実体からデジタル側への一方向のデータ連携と、デジタル側から実体への自動反映を含む双方向連携を区別します。監視のための読み取りと、実機へ影響を与える書き戻しを同じ経路で扱うと、権限や安全性の境界が曖昧になります。
四つのデータクラスに分ける
制御・安全状態
関節状態、ベース状態、インターロックなどは、シミュレーションの状態推定や安全判断に直接影響します。値には取得時刻とシーケンス番号などの順序情報を付け、受信時刻だけで実機状態の時刻を表さないようにします。
OPC UAのデータモデルにあるSourceTimestampとServerTimestampのように、値が生成された時刻とサーバーが受け付けた時刻を分ければ、通信遅延や到着順を分析できます。
環境・シーン情報
周囲の物体、作業空間、配置、経路などは、制御状態と同じ周期で送る必要があるとは限りません。配置変更やシーン再構成をイベントとして同期し、シミュレーション側では、どの時点の環境を表す情報かを保持します。
モデル・保全情報
ロボットの形状、質量、摩擦などのパラメータ、再キャリブレーション結果、劣化状態、保全履歴は、モデル再同定や保全イベントを更新トリガーにします。高頻度に送るより、変更理由、適用範囲、バージョンを管理する方が、検証と保全に向いています。
運用ログ
運用ログには、実機側の取得時刻、受信時刻、クロックの種類、シーケンス番号、通信状態、モデル・設定バージョンを残します。シミュレーション入力用のデータと、改変しない原記録を分離すれば、再生検証と監査に利用できます。
flowchart LR
subgraph Physical["実機"]
Sensor["センサー・計測"]
Controller["制御器"]
RobotState["関節・姿勢・トルク・安全状態"]
Scene["環境・シーン情報"]
Model["モデル・保全情報"]
Events["イベント・運用ログ"]
Sensor --> RobotState
Controller --> RobotState
Scene --> Events
Model --> Events
RobotState --> Events
end
subgraph Ingest["収集・記録"]
Collector["データ収集"]
Timestamp["時刻・順序付与\nSourceTimestamp / ServerTimestamp / シーケンス番号"]
RawLog["不変の原記録\n取得時刻・受信時刻・通信状態・版情報"]
Collector --> Timestamp
Timestamp --> RawLog
end
subgraph Gate["同期契約・判定"]
Contract["データクラス別の同期契約\n更新トリガー・鮮度上限・欠損時動作・権威性"]
QoS["QoS判定\nReliability・Deadline・Durability・History・Liveliness"]
Freshness["鮮度・順序・版の検査"]
Contract --> QoS --> Freshness
end
subgraph Twin["シミュレーション"]
SimInput["シミュレーション入力"]
SimTime["シミュレーション時刻"]
Sim["デジタルツイン"]
SimInput --> SimTime --> Sim
end
RobotState --> Collector
Scene --> Collector
Model --> Collector
Events --> Collector
Timestamp --> Contract
Timestamp --> RawLog
Freshness --> SimInput
RawLog --> Replay["再生・監査・再現検証"]
Sim --> CommandGate["コマンドゲート\n認証・認可・妥当性検査・範囲制限・監査"]
CommandGate -. "双方向反映が必要な場合のみ" .-> Controller時刻と実行方式を分ける
シミュレーション時刻は壁時計時刻と同一ではありません。ROS 2ではシステム時刻、安定した経過時間を扱う時刻、ROS時刻を区別でき、シミュレーション時には/clockでROS時刻を提供できます。ROS時刻は一時停止、速度変更、時刻ジャンプの影響を受けるため、受信時刻や単調増加する経過時間と混同しない設計が必要です。
用途ごとに、実時間追従、ロックステップ、イベント駆動、オフライン再生を使い分けます。
| 実行方式 | 主な用途 | 同期の考え方 | 注意点 |
|---|---|---|---|
| リアルタイム追従 | 運用監視 | 実機の進行に合わせて更新 | 遅延や期限超過を監視する |
| ロックステップ | 制御検証 | 入力と計算の順序をそろえる | 欠損や順序逆転を検出する |
| イベント駆動 | シーン、保全、モデル更新 | 状態変更を契機に反映 | イベントの正当性を管理する |
| オフライン再生 | 再現検証、what-if解析 | 保存済み時刻と順序を再現 | ログの時刻と版情報が必要 |
同期契約とQoS
同期契約には、少なくとも次の項目を含めます。
- データが表す時間と基準クロック
- 許容される鮮度と最大遅延
- 欠損、重複、順序逆転、遅延時の動作
- 最新値を保持するか、履歴を蓄積するか
- 正当な書き込み元
- モデルや設定のバージョンとの対応
- シミュレーション結果を実機状態として扱える条件
DDSやROS 2では、Reliability、Deadline、Durability、History、LivelinessなどのQoSをデータごとに設定できます。したがって、周期だけでなく、期限超過時の扱い、再送の要否、履歴の深さ、最後の有効値を保持するかどうかまで決めます。センサー、状態、命令に同じ設定を適用できるとは限りません。
| データクラス | 更新トリガー | 粒度 | 欠損時の基本方針 | 保存方法 |
|---|---|---|---|---|
| 制御・安全状態 | 制御・計測周期、状態変化 | 実機の時間進行に近い粒度 | 有効期限を定義する | 時刻・順序付き記録 |
| 環境・シーン | 配置や周辺状態の変更 | 状態変更イベント | 旧シーンとの混在を防ぐ | シーン版と適用時刻を保存 |
| モデル・保全 | 再同定、校正、保全 | 変更イベントまたは低頻度 | 未承認版を適用しない | 版と変更理由を保存 |
| 運用ログ | データ取得・イベント発生 | 連続またはイベント記録 | 欠損自体を記録する | 原記録を改変せず保存 |
制約と失敗しやすい点
第一の失敗は、すべてを最新値へ上書きすることです。これでは通信遅延、順序逆転、モデル版の違いを後から検証できません。第二は、壁時計時刻とシミュレーション時刻を同一視することです。停止や速度変更を含む再生で、実機との時系列対応が崩れます。
第三は、QoSを既定値に任せることです。欠損を許容できるセンサー値と、期限超過時に安全側へ遷移すべき状態は異なります。第四は、シミュレーション出力をそのまま実機へ書き戻すことです。双方向反映では、認証・認可、妥当性検査、範囲制限、フェイルセーフ、監査ログを備えたコマンドゲートを経由させます。
採用判断の進め方
まず、目的を監視、リアルタイム制御検証、再現可能な試験、計画・what-if解析、保全のどこに置くか決めます。次にデータクラスごとに、権威ある値、許容鮮度、最大遅延、欠損時の動作を定義します。実機時刻、受信時刻、シミュレーション時刻、ログ再生時刻も分けて保存します。
固定のHzや最大遅延を、すべてのロボットに一般化することはできません。実機と通信経路を計測し、同期契約を満たさない入力は、最新の実機状態として扱わない運用が必要です。
まとめ
デジタルツインの同期設計では、全データを同時に送るのではなく、制御・安全状態、環境・シーン、モデル・保全、運用ログを分離します。それぞれに時刻、更新トリガー、QoS、鮮度上限、欠損時の動作、データの権威性を割り当てます。
実機状態をシミュレーションへ反映するだけでなく、「いつの状態を、どの版のモデルで、どの順序に受け取ったか」を再現できることが、検証基盤や保全基盤として運用するための条件です。
参考情報
- ISO 23247-1:2021 — Digital twin framework for manufacturing
- ISO 23247-2:2021 — Reference architecture
- Digital Twin in manufacturing: A categorical literature review and classification
- Digital Twin: Enabling Technologies, Challenges and Open Research
- OMG Data Distribution Service Version 1.4
- ROS 2 Design: Clock and Time
- ROS 2 Documentation: About Quality of Service settings
- OPC UA Part 8: Data Access
- NISTIR 8356: Cybersecurity Considerations for Digital Twin Technology
同期の細かさよりも、データが表す時刻と、その値を信頼できる条件を明確にすることが実装の出発点になります。
AI利用に関する注記
本サイトの記事は、複数のAIエージェントによる調査・執筆・レビューを経て公開しています。正確性と品質の向上に努めていますが、内容については必ず一次情報をご確認ください。
