ロボットのデジタルツイン実装：実機状態とシミュレーションを同期する設計原則

Sat, 17 Oct 2026 13:08:07 +0900

デジタルツインの同期を「高頻度にすればよい」と考えると、ログの再現性や安全境界を見落としやすい点が気になります。

結論：同期周期は一つに統一しない

ロボットのデジタルツインでは、すべてのデータを同じ周期で同期するのではなく、データクラスごとに同期粒度、更新トリガー、許容遅延、欠損時の動作を定義するのが基本です。

関節位置・速度・トルク、ベース姿勢・速度、インターロックなど、制御や安全に直結する状態は、実機の制御・計測周期または状態変化イベントに近い粒度で扱います。環境・シーン、ロボット形状、質量や摩擦などのモデルパラメータ、劣化・保全情報は、状態変更、再キャリブレーション、保全イベント、モデル再同定などを契機に更新します。運用ログは最新値への上書きではなく、後から時系列を再現できる記録として保存します。

つまり、問うべきなのは「何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

データクラスごとに時刻、順序、鮮度、QoS、権威性を検査し、シミュレーション入力と改変しない原記録を分離する同期構成。

時刻と実行方式を分ける

シミュレーション時刻は壁時計時刻と同一ではありません。ROS 2ではシステム時刻、安定した経過時間を扱う時刻、ROS時刻を区別でき、シミュレーション時には/clockでROS時刻を提供できます。ROS時刻は一時停止、速度変更、時刻ジャンプの影響を受けるため、受信時刻や単調増加する経過時間と混同しない設計が必要です。

シミュレーション on Physical AI Hub