hakoniwa-conductor

分散シミュレーションにおける 因果性制御 ―箱庭のアプローチ― 合同会社箱庭ラボ CTO 森崇

アジェンダ • 従来の箱庭の構造と反省点 • 分散化によって顕在化する課題 • 分散シミュレーションでの箱庭のアプローチ • 既存の分散シミュレーションとの比較 • 最新箱庭のデモ（Rd-Light） • 最新箱庭のアーキテクチャと課題 • 今後の展開 2

従来の箱庭の構造と反省点 クラウド環境 [凡例] 箱庭アセット 箱庭アセット 箱庭コンダクタ 箱庭 コンポーネント 箱庭API 箱庭PDU通信 シミュレーション 時刻 負荷分散用 コンピュータ 箱庭PDUデータ 箱庭時刻 既存の シミュレータや プログラム 箱庭コア 現実空間 箱庭ブリッジ 箱庭コア機能 3

箱庭時刻同期とは何か • 箱庭の時刻同期方式 • 中央制御方式ではなく，並列化が容易な分散制御方式でのシミュレーション時刻同期方式 • 仕組み(ハーモニー) • 各シミュレータは 箱庭時間(マエストロ)をみながら， シミュレーション時間調整し時間同期する(ハーモニー) 4

箱庭のPDUとは何か • 箱庭のPDU(Protocol Data Unit)は、箱庭アセットが互いに通信するためのデータ単位です。 • PDUデータ型の定義： ROS IDL (Interface Definition Language) というインターフェース記述言語 • PDUデータは、様々な通信プロトコルを介してデータ交換されます。 • UDP, MQTT, ROS, Zenoh, 共有メモリ 5

• https://docs.ros.org/en/rolling/Concepts/Basic/About-Interfaces.html

箱庭 Runtime Delegationとは何か 【QUEST3ノード】 【QUEST3ノード】 【QUEST3ノード】 ドローン ドローン ドローン シミュレーション シミュレーション シミュレーション 【共有SIMノード】 荷物の重力＆運搬の シミュレーション SIM1 (ドローン) SIM1 (TWIN) ΔT QUEST3側から見た動き https://www.youtube.com/watch?v=0N4g3U6ClrM SIM2-1 (荷物運搬) ΔT SIM2 (TWIN) SIM2-2 (重力) 荷物運搬時は、 2ΔTの遅延が発生する！ 荷物運搬時の荷物の動きが、ドローンに追従しない！ 荷物は共有資源のため、共有シミュレーション用のノードに配置 重力シミュレーションと荷物運搬はノード２で動かし、ノードは１TWINとした ΔTを小さくすれば良いと言うのも１つの解決案ではあるが、 通信オーバーヘッドが大きくなり、現実解にならないケースもある。 6

• https://www.youtube.com/watch?v=0N4g3U6ClrM

箱庭 Runtime Delegation 【QUEST3ノード】 【QUEST3ノード】 【QUEST3ノード】 ドローン ドローン ドローン シミュレーション シミュレーション シミュレーション 【共有SIMノード】 荷物の重力＆運搬の シミュレーション SIM1 (ドローン) SIM1 (TWIN) ΔT https://www.youtube.com/watch?v=BiP74y4mLNc 荷物運搬イベント発生 SIM2-1 (荷物運搬) SIM2 (TWIN) ΔT SIM2-1 (荷物運搬) SIM2-2 (TWIN) (重力) 荷物運搬のトリガーイベント発生時に、荷物運搬のシ ミュレーション権限を獲得することで、ドローンと荷物の 動きが同期して動けるようになる！ シミュレーション実行権限は、 シミュレーション責任のある最も適切な場所に移す。 それがRuntime Delegation。 7

• https://www.youtube.com/watch?v=BiP74y4mLNc

反省点 ずっと、実装ありきで突き進んできましたが、、、 「分散シミュレーション」という文脈において、 • 箱庭時刻同期をもう一度捉え直したい • 今は、最大許容遅延時間(d_max)以内での時刻同期ができるというもの • それの意味はなに？ちょっと曖昧なきがしており。 • 箱庭PDUをもう一度捉え直したい • 今は、箱庭アセット間のデータ交換の標準的なデータ仕様 • 箱庭RuntimeDelagationを正式対応したい • 今は、プロトタイプ実装しかない やれるのは、 箱庭ラボ３年計画最後の今しかない！！ 8

分散化によって顕在化する課題 • 分散化によって顕在化するもの： • モデル間のデータと通信 • プロセス間の時刻のズレ • →通信遅延により因果関係の観測が遅れる • つまり： • 時刻は暗黙に同期されなくなる • 実行順序と因果順序が 一致しなくなる可能性がある プロセスA プロセスB 制御モデル 物理モデル センサデータ 時刻 制御データ 分散シミュレーション基盤 9

単一プロセスにおける時間と因果性 • 単一プロセスでは： • 実行順序が定まっている • スケジューラが逐次実行する • 新しい状態が即時反映される • つまり： • 時刻は暗黙に同期される • 実行順序がそのまま因果順序となる 単一プロセス センサデータ 制御モデル 制御データ 物理モデル ※ 逐次更新構造（Gauss–Seidel 型に類似） 10

分散シミュレーションでの箱庭のアプローチ • 箱庭の場合： • 各モデルを EU (実行単位)として扱う • 箱庭アセットは複数のEUを持つ • 箱庭コア機能が論理時刻を管理する • 各箱庭アセットの時刻は有界ドリフト アセットA アセットB 有界ドリフト RDによる実行権の移動 <EU> 物理モデル <EU> 物理モデル (時刻のズレはd_max以内に収まる) • 因果性保証はRDで実現 • つまり： • 時刻を揃えることが目的ではない • 観測可能な因果が崩れないことが目的 • 状態の決定責任は常に単一であるべき • 因果が発生する場所に実行責任を移す <EU> 制御モデル センサデータ 箱庭時刻 制御データ 箱庭コア機能 11

既存アプローチの時間管理方式（FMI） • FMIの場合(Co-Simulation)： • 各モデルを FMU として扱う • マスターアルゴリズム（MA）が時間を進める • 時間はステップ単位で同期される • 規格はFMUのI/Fのみを定義 （時間管理の実装はMA依存） • つまり： • FMIは規格として、 • 時刻同期は暗黙的にMAが行う • 因果関係の扱いはマスター実装に依存する • ステップ内因果は規格としては規定されない (FMI 3.0でも構造自体は変わっていない) プロセスA プロセスB <FMU> 制御モデル <FMU> 物理モデル センサデータ 時刻 制御データ マスターアルゴリズム(MA) ※ Jacobi 型（同時更新） 12

既存アプローチの時間管理方式（HLA） • HLAの場合： • 各モデルを Federate として扱う • RTIが論理時刻を管理する • 各FederateはRTIから 時間前進の許可を受けて進む • つまり： • RTIは、 • 「各Federateの宣言したLookaheadを前提に」 因果違反を起こさないように時間を仲裁する • Time Advance Request (TAR) • Time Advance Grant (TAG) • Lookahead • Timestamp Ordered Delivery プロセスA プロセスB <Federate> 制御モデル <Federate> 物理モデル センサデータ 時刻 制御データ Logical Time Management RTI（Run-Time Infrastructure） 13

HLA補足（１／２） ④Federate Aは、Ta+L_aまで時刻を進める イベント Lookahead：L_a Federate A 現在時刻：Ta ①TAR受信(T_req) (Ta+L_a) ③TAG送信 ④RTI は、内部状態として「AはTAG済み」と記録 RTI ②RTIはLBTSを計算し、T_req ≤ LBTS が成立すれば TAG を送る TAG_A = min( T_req, LBTS )、LBTS = min_i (Ti + Li) Lookahead：L_b イベント Federate B 現在時刻：Tb 14

HLA補足（２／２） Ta Lookahead：L_a Ea イベント Federate A ①TAG受信後、 Ta+L_aまで時刻を進める ②イベントをRTIに送信する タイムスタンプ付きメッセージ(T_event) T_event のタイムスタンプ：Ta+La+Ea RTI ③TAR受信(T_req) (Tb+L_b) ④T_event ≤ LBTS なのでイベント配送 （TSO）（TAGは別途判定） Timestamp Ordered Delivery Federate B Tb Lookahead：L_b 15

既存の分散シミュレーションとの比較 HLAは「常時厳密」 FMIは「常時ステップ同期」 箱庭は「通常は緩く、臨界点だけ厳密(Dual-Mode Causality System)」 比較項目 FMI HLA 箱庭 時刻同期 MAが暗黙的に管理（ステップ単位） RTIが論理時刻を明示的に管理 （TAR/TAG） 箱庭時刻同期による有界ドリフト (Dmax) 因果性保証 規格として規定なし（MA実装依存） Lookahead＋TSOで厳密に保証 RDによる動的実行責任の移動 実行性能 軽量・高速（同期オーバーヘッド小） ブロック待機が発生、スケーラビリティ課題あり リアルタイム性能重視 スケーラビリティ 単一ノード内での結合に特化 ネットワーク分散に特化 （Scale-up型: メモリ共有で高速だが、 （Scale-out型: 複数のPCをつなげるが、 PC1台の性能限界に縛られる） 通信遅延により同期制御が難しくなる） 単一ノード、ネットワーク分散を選択 実装コスト 低い（FMU I/Fのみ） 高い（Federate側もRTI側も複雑） 中(RDの実装は若干ムズイかも：課題) 適用領域 産業・組込みシミュレーション向け 軍事・大規模分散シミュレーション向け ドローン配送、工場のロボット協調など。 [ドローン配送] 通常：飛行経路、通信遅延あり、全体停止不可 でも：着陸直前、障害物接近、編隊交差、ここは精密同期したい。 [工場のロボット協調] 通常：各ロボット独立動作、ゆるい同期 でも：物理的接触、協調把持、ワーク受け渡し、ここだけ厳密。 16

箱庭の立ち位置 • リアルタイム性能 • 全体停止型の厳密同期は採らない • 意味のある因果保証 • すべての因果を保証しない、 ユーザが観測したい因果のみを守る 全体同期強制度 HLA （あくまでもイメージです） FMI （観測因果のみ保証） 箱庭 （リアルタイム性重視） ROS2/Gazebo リアルタイム性（高） 17

箱庭の因果性の考え方 世界５ 普段はバラバラな世界で、 それぞれ独立して緩く接続している そんな関係性の中で、 世界１ 世界４ 観測者にとって、 意味のある条件下においてだけ、 因果性を動的に成立させる 世界２ そんだけ。 動的に実行権を移動(RD) 世界３ 観測者 観測スコープ 箱庭時刻同期による 緩い接続(Dmax) •観測スコープ：守りたい因果の範囲（EU集合＋PDU集合＋評価指標） •観測者：因果を「意味がある」と判断する主体（ユーザ/運用/AI/アプリ） 18

新しい用語の整理 • Hakoniwa Asset（箱庭アセット） • OSプロセスとして実行される単位。1つ以上の実行ユニット（EU）を含む。 • 実行ユニット（EU: Execution Unit） • 分散環境において同一の論理モデルを表す実行エンティティ。 EUは論理的な存在であり、複数のアセットにわたってインスタンスを持つ場合がある。 • オーナー / 非オーナー（Owner / Non-Owner） • EUの状態更新およびPDU書き込みに責任を持つエンティティ / その責任を持たないエンティティ。 • エポック（Epoch） • EUの実行責任（オーナー）が一意に定まっている期間を示す世代番号。 • コミットポイント（Commit Point） • コンダクターの状態遷移に基づき、エポックの更新がシステム全体で合意される境界。 そのエポックの実行結果と責任が意味論的に確定する。 • ランタイム委譲（RD: Runtime Delegation） • 実行中にEUのオーナーを安全に切り替えるためのメカニズム。 • コンダクター（Hakoniwa Conductor） • EUの実行責任遷移を管理し、エポック更新を制御し、コミットポイントを確立するエンティティ。コンダクターは数値計算を行わず、実行戦略やソルバーの決定も行わない。 • データプレーン（Data Plane） • シミュレーションに必要な実行データ（PDU等）の送受信・更新・時間進行を担うドメイン。 • コントロールプレーン（Control Plane） • 実行責任の移譲、世代管理、因果境界の確定、ポリシーの適用を担うドメイン。 19

単一オーナーの不変条件 状態の決定責任は常に一箇所に存在 EU （オーナー） 任意の時刻tにおいて、 各PDUの書き込みオーナーは 高々1つである。 EU （非オーナー） Invariant: ∀t, ∀PDU, WriteOwner(PDU, t) は高々1つ PDUの読み込みは、 複数のEUで可能である。 ∀t, ∀PDU, |Readers(PDU, t)| ≥ 0（制限なし） PDU EU （非オーナー） EU （非オーナー） この不変条件があるため、実行権の移譲（RD）は衝突なく成立する。 20

箱庭アセット/EU/PDUの関係性 ・箱庭アセットは複数のEUを持つことができる ・EUは、不変条件の範囲でPDUアクセスする 箱庭アセット 箱庭PDU 箱庭アセット Drone-1 位置情報 EU(Drone-1) EU(Control-1) Drone-1 移動指示 Drone-2 位置情報 EU(Drone-2) EU(Control-2) Drone-2 移動指示 21

ランタイム委譲 ・切り替え元/先の 箱庭アセットは、EUを持つ ・実行権を持つ EUがシミュレーションを実行する ・切り替え条件は、 観測者（ユーザ）が決める ・切り替え発生すると、 切り替え元EUは待機状態になり、 切り替え先EUが動き出す 切り替え前： 箱庭アセット EU(Forklift) 箱庭PDU 箱庭アセット 移動指示 EU(Controller) 箱庭アセット EU(Forklift) 位置情報 観測者 切り替え後： 箱庭アセット EU(Forklift) 箱庭PDU 箱庭アセット 移動指示 EU(Controller) 位置情報 箱庭アセット EU(Forklift) 22

コンダクタ/ブリッジ/エポックとコミットポイント EUコンテキスト コンテキスト復帰 コンテキスト保存 EU （切り替え元） EU （切り替え元） EU （切り替え先） EU （切り替え先） 実行権を破棄 EU状態 実行権を獲得 Stable Releasing Activating Stable 0 0 1 1 Owner PDU Epoch 箱庭コンダクタ/ブリッジ ★コミットポイント Owner PDUのEpochが更新される時刻 →PDUデータ転送において、古いEpochの PDUは自動的に破棄される 23

RDにおけるDmaxの意味付け Dmaxは、因果を保証するための同期ではない。 観測者が意味あると判断する因果を安全に成立させるための、時間的許容幅である。 Drone-1 箱庭の時刻同期は、アセット間の論理時刻差が Dmax 以内であることのみを保証する。 因果は RD により成立し、Dmax はその成立条件を時間的に保護する。 例： ドローンが5m/secで移動しているとする。 RD発動条件として、X座標として、１００m境界でゾーンを２分するとする。 よって、その判断周期は、ドローンの速度とDmaxで安全に決めることができる。 仮にDmax=10msであった場合、 距離誤差=速度×Dmax =5×0.01=0.05m つまり、最大 5cm の位置ズレが発生しうる。 ゾーン１ ±5cm Drone-2 100m 安全マージン ゾーン２ 100m よって、RD発動条件の判定境界は、 少なくともこの誤差幅（5cm）を安全マージンとして考慮して設計される必要がある。 （ΔXmax​=Vmax​⋅Dmax） したがって、Dmaxは「時間の上限値」ではなく、 「因果成立を保証するための物理誤差の上限値を設計可能にするパラメータ」である。 24

最新箱庭アーキテクチャ [RDなし] • ユーザ定義領域： • 箱庭アセット • 箱庭提供領域： • 箱庭コア機能 • 箱庭時刻同期/共有メモリベースでのPDU通信/アセット管理 • 箱庭PDUエンドポイント • 箱庭PDU通信の抽象化レイヤ（SHM/TCP/UDP/WS） • 箱庭PDUブリッジ • PDUデータの転送方式を制御（Immediate /Throttle /Ticker） コントロールプレーン 箱庭RDモニタ 箱庭コンダクタ 箱庭PDUブリッジ データプレーン 箱庭RD アセットEU 箱庭アセット • 箱庭コンダクタ • 分散シミュレーション向けのノード間調停 [RDあり] • ユーザ定義領域： • 箱庭RDモニタ • EUのコンテキスト切り替え条件を管理 箱庭PDUエンドポイント 箱庭コア機能 • 箱庭RDアセットEU • EUの切り替えノード選定ルールを管理 25

最新箱庭アーキテクチャの特徴 箱庭は「実行責任を宣言可能にした分散シミュレーション基盤」 • 関心の分離 • 責務に応じてコンポーネントを設計 • 宣言型中心 • 通信・転送・実行責任をすべてJSONで定義 • 再コンパイル不要 • 実行構成を動的に変更可能 • 目的： • 人間が理解しやすい • AIが解釈しやすい • 将来的にはAIが実行責任配置を最適化する世界を目指す • デメリット • コンフィグファイルが大量にできる（→コンフィグは、自動生成に舵切ってます）。 26

箱庭PDUエンドポイント 箱庭PDUの出入り口 • 1つのエンドポイントで、複数PDUのI/Oを実現 箱庭アセット • I/O対象のPDUはPDU定義ファイルで指定 • 宣言(JSON)中心で、実装と接続を分離 • すべてはJSONファイルで！ 箱庭PDU • PDU：データ構造定義 • Endpoint：接続仕様定義 箱庭PDU エンドポイント Endpoint 定義ファイ(JSON) キャッシュ 通信 BUFFER 箱庭アセット QUEUE PDU 定義ファイ (JSON) TCP SHM UDP WebSocket 箱庭PDU 箱庭PDU 共有メモリ(箱庭コア機能) LAN 27

箱庭PDUブリッジ 箱庭PDUの転送 箱庭PDUブリッジ接続 • 1つのブリッジ接続で、複数PDUを転送 • 宣言(JSON)中心で、実装と接続を分離 • すべてはJSONファイルで！ 転送ポリシー 転送対象 PDU群 Immediate Throttle Ticker • Bridge：転送仕様定義 Bridge 定義ファイ(JSON) 転送元 箱庭PDU エンドポイント PDU転送 転送先 箱庭PDU エンドポイント 箱庭PDU 箱庭PDU 箱庭アセット 箱庭アセット 28

箱庭コンダクタ 箱庭時刻の同期とPDUデータ転送 • ノード間時刻同期（Dmax制約） • Dmax: 最大許容遅延時間 • PDU転送進行制御 srv-01 • 参加ノード定義 [凡例] 箱庭コア機能 • 宣言(JSON)中心で、実装と接続を分離 • すべてはJSONファイルで！ 箱庭時刻 Dmax • コンダクタ：参加ノード定義 • データ転送：Bridge定義ファイル • 通信定義：Endpoint定義ファイル 箱庭コンダクタ 01 コンダクタ 定義ファイ(JSON) 箱庭コンダクタ 02 Dmax 箱庭アセット 01-03 箱庭アセット 01-02 PDUデータ Dmax 箱庭アセット 01-01 箱庭コンダクタ 01 箱庭コンダクタ 02 箱庭アセット 02-01 箱庭アセット 02-02 箱庭コア機能 箱庭コア機能 cli-01 cli-02 箱庭アセット 02-03 29

Hakoniwa Distributed Simulation Overview Hakoniwa is a PDU-centric distributed simulation framework in which simulation components are distributed across multiple nodes while preserving a consistent logical structure and coordinated simulation time. Node-1 Node-2 Each Node represents an independent execution environment (process or machine). Nodes are connected via PDU-based communication, rather than shared global state. The Hakoniwa Conductor also serves as a PDU forwarding component of the Hakoniwa Bridge. PDU (Protocol Data Unit) A PDU is the fundamental unit of data exchange in Hakoniwa. - A PDU has a single owner - Only the owner may write to the PDU - Multiple readers may observe the PDU PDU Storage Types - PDU (SHM) Stored in shared memory for fast local access - PDU (Cache) Stored as a cached snapshot, typically within a PDU Bridge [Legend] PDU communication Hakoniwa PDU Bridge Hakoniwa Conductor(master) Hakoniwa Asset (non-time-synchronized) Hakoniwa Conductor(slave) PDU Write (source: owner) PDU Read Node-3 Hakoniwa Asset (time-synchronized) PDU (SHM) Mirror PDU(SHM) PDU (Cache) PDU Remote Read

リポジトリ構成 アセット層 hakoniwa-pdu-rpc hakoniwa-pdubridge-core hakoniwa-pdu-endpoint プロトコル層 未作成 作成済み <<private>> hakoniwa-rd-core hakoniwa-remote-api 転送層 [凡例] <<private>> hakoniwa-conductor-pro ・転送ポリシー: immediate / throttle / ticker ・PDU転送設定（可変設定）と epoch ・ルーティング（channel/endpoint の解決） ・箱庭PDU通信端点 ・通信インタフェース仕様定義 ・通信インタフェーステスト

• https://github.com/hakoniwalab/hakoniwa-pdu-bridge-core
• https://github.com/hakoniwalab/hakoniwa-pdu-endpoint
• https://github.com/hakoniwalab/hakoniwa-pdu-rpc
• https://github.com/hakoniwalab/hakoniwa-remote-api

箱庭 Runtime Delegation Core 分散ノードで実行権を矛盾なく委譲する仕組みが必要！ cli-01 EU(オーナー) EUコンテキスト引き継ぎ EU(待機) cli-02 EU単位の状態管理 箱庭PDU 箱庭PDU Owner Stable 箱庭PDU 箱庭PDU Owner Releasing 箱庭PDUブリッジ (cli-01) Owner Activating 箱庭PDUブリッジ (cli-02) ブリッジ接続の再配管 箱庭PDUブリッジ (srv-01-01) srv-01 箱庭PDUブリッジ (srv-01-02) 共有メモリ 32

箱庭 Runtime Delegation Core 分散ノードで実行権を矛盾なく委譲する仕組みが必要！ cli-01 EU(オーナー) 箱庭RDアセットCore EUコンテキスト引き継ぎ EU(待機) cli-02 EU単位の状態管理 箱庭PDU 箱庭PDU Owner Stable 箱庭RDコンダクタCore Owner 箱庭PDU 箱庭PDU Releasing 箱庭PDUブリッジ (cli-01) Owner Activating 箱庭PDUブリッジ (cli-02) ブリッジ接続の再配管 箱庭RDブリッジCore 箱庭PDUブリッジ (srv-01-01) srv-01 箱庭PDUブリッジ (srv-01-02) 共有メモリ 33

Runtime Delegationイベントの流れと状態遷移 ————————イベントの流れ———————— Domain ExMonitor <<PDU>> RuntimeStatus 自分のコンテキストを PDUとして送信 <<PDU>> Runtime Context Executor (Owner) コンテキストは、 機体数(100個)必 要になる ExecutionUnit毎に 存在 <<PDU>> <<PDU>> <<PDU>> Runtime Next NextNode ExNode ExNode 次のExecutionUnit の対象を決めて、 Status に書き込む execution unit ownerに対応する connectionとのマッ ピングが必要 ExecutionUnit毎 にStatusは１個 —————状態の流れ————— OwnerStable Conductor (Master) <<PDU>> RuntimeStatus OwnerReleasing Statusに応じて、 ルートの再設定 次のExecutor候補は、 ExMonitorがStatusを定 期チェック、Context引き 継いだら、コンテキストを 送信する Executor (NonOwner) Bridge Bridge Bridge <<PDU>> <<PDU>> Runtime <<PDU>> BridgeEpoch Epoch BridgeEpoch Conductor (Master) 次のExecutorの対象を決 めて、Statusに書き込む Conductor (Master) OwnerReleasing 中は、一時 的に PDU 転送が停止するが、 owner の一意性という不変条 件は常に維持される。 OwnerActivating <<PDU>> <<PDU>> <<PDU>> Runtime Next NextNode ExNode ExNode

RDデモ構成 cli-01 5sec間隔でplantがcli-01とcli-02を交互に移動する 10msec cli-01 箱庭コンダクタ （Client) 10msec 10msec srv-01 1sec Reader 10msec Writer controller Reader <<pdu>> srv-01.time 1sec cli-02 箱庭コンダクタ （Client) Writer 10msec <<pdu>> cli-01.time srv-01-01 箱庭コンダクタ （Server） master plant cli-02 ExMonitor immediate(10ms) 10msec <<pdu:1>> Drone.pos <<pdu>> cli-02.time <<pdu>> srv-01.time srv-01-02 箱庭コンダクタ （Server） <<pdu:0>> Drone.motor immediate(10ms)

最新箱庭のデモ（Rd-Full） ５秒間隔で、シミュレーション実行体（EU: plant）がcli-02に移って、また戻ってを繰り返します。 cli-02: EU(plant) cli-01: EU(plant) EU(ctrl) cli-01: Conductor cli-02: Conductor srv-01: ExMonitor srv-01-01: Conductor srv-01-02: Conductor 36

37

RD-Lightの振る舞い：EU（実行体）の移動 • 切り替え判断は、EU(Forklift)が行う • ユーザ判断に委ねる設計方針 切り替え前： 箱庭アセット • EU(Controller)は切り替えを知らない • 切り替えは、制御プレーン用のPDUを利用 (箱庭が提供するPDU：hakoniwa-pdu-registry) EU(Forklift) 箱庭PDU 箱庭アセット 移動指示 EU(Controller) 箱庭アセット EU(Forklift) 位置情報 • 切り替え判断結果： ExecutionUnitRuntimeStatus ノード１ • EUの切り替え状態および切り替え中は次のノードIDが入る • EUの切り替えコンテキスト： ExecutionUnitRuntimeContext • EUのコンテキストデータを管理 • 物理シミュレーション毎に異なるため、byte配列（可変長） 切り替え後： 箱庭アセット EU(Forklift) 箱庭PDU 箱庭アセット 移動指示 EU(Controller) 位置情報 箱庭アセット EU(Forklift) ノード１ 38

• https://github.com/hakoniwalab/hakoniwa-pdu-registry

最新箱庭のデモ（Rd-Light） • RD-Lightとは？ • RD-Full実装の簡易版 オーナー 待機 待機 オーナー • 分散ノード構成は未サポート • →RDのイメージを理解してもらうために作成した • EU：MuJoco/Controller • 構成：１ノード／２プロセスのRDデモ • 左：初期オーナーEU • 右：待機EU • 制御内容： • フォークリフト右に2m進めて、元に戻ることを繰り返す • RD発動条件： • 1m未満：左がオーナー • 1m以上：右がオーナー https://www.youtube.com/watch?v=xaJJ1wEgNR8 39

• https://www.youtube.com/watch?v=xaJJ1wEgNR8

最新箱庭の課題と方向性 [課題] 「RDはまだ早いかも...」 • 現場の痛みに直結するユースケースはまだ見えない • たぶん、ドローン配送を１００台同時でやるときの最適化戦略評価としてやるとかはあるかも。 [方向性] 「RDよりも、負荷分散路線でやる」 • ドローン100台同時シミュレーションで、バーチャルドローンショー！ • ドローンショー企業からも、「欲しい！」っていう声が上がっている（ペインがある！） [まとめ] 「RDは、これから育てていくもの」 • まずはビジネスニーズにマッチするユースケースの探索 40

今後の展開 ドローン100台同時シミュレーション ー雨天時は仮想空間で バーチャルドローンショー！ ー ラズパイ10台使ってドローンショー！ 41

2026年3月13日時点の成果 • 1024台同時シミュレーション達成！ • デモ動画： https://www.youtube.com/watch?v=tjFdWPEMs7E&t=11s 42

• https://hakoniwa-lab.net/2026/03/13/news-35/
• https://www.youtube.com/watch?v=tjFdWPEMs7E&amp;t=11s