---
title: hakoniwa-conductor
tags:  #hakoniwa  
author: [森崇](https://convert.docswell.com/user/kanetugu2015)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/LJ3W54LGJ5.jpg?width=480
description: # 分散シミュレーションにおける因果性制御 ― 箱庭のアプローチ ―  本資料では、分散シミュレーション環境において発生する**因果関係の崩れ**という問題に対して、箱庭（Hakoniwa）が採用しているアプローチを紹介します。  単一プロセスのシミュレーションでは、実行順序がそのまま因果順序となるため、状態更新の整合性は自然に保たれます。しかし、シミュレーションを複数ノードや複数プロセスへ分散すると、通信遅延や処理タイミングの差によって、**実行順序と因果順序が一致しなくなる問題**が発生します。  既存の分散シミュレーション技術としては、FMI（Functional Mock-up Interface）やHLA（High Level Architecture）などがあり、これらは主に**時間同期**によって因果関係を維持します。一方で箱庭では、  * 箱庭時刻同期による **有界ドリフト（Dmax）** * **Runtime Delegation（RD）** による実行責任の動的移動 * **単一オーナー不変条件（Single Owner Invariant）**  といった仕組みを組み合わせることで、**すべての因果を厳密に同期するのではなく、観測者にとって意味のある因果のみを保証する**という設計思想を採用しています。  本資料では、以下の内容について解説します。  * 分散化によって顕在化する因果性の問題 * FMI / HLA との比較による箱庭の立ち位置 * Runtime Delegation による実行責任の動的移譲 * Dmax の工学的な意味付け * 箱庭の最新アーキテクチャとデモ構成  また、2026年3月時点での成果として、**1024台のドローンを対象とした同時シミュレーション**の実行例についても紹介しています。  分散シミュレーション基盤やロボット協調システム、デジタルツイン、リアルタイムシミュレーションなどに関心のある方にとって参考になれば幸いです。
published: March 14, 26
canonical: https://convert.docswell.com/s/kanetugu2015/KGNE3Q-hakoniwa-conductor
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/LJ3W54LGJ5.jpg)

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


# Page. 2

![Page Image](https://bcdn.docswell.com/page/8JDKDQNNEG.jpg)

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


# Page. 3

![Page Image](https://bcdn.docswell.com/page/VEPKXL5N78.jpg)

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


# Page. 4

![Page Image](https://bcdn.docswell.com/page/27VVLQPY7Q.jpg)

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


# Page. 5

![Page Image](https://bcdn.docswell.com/page/5JGLXWPW7L.jpg)

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


# Page. 6

![Page Image](https://bcdn.docswell.com/page/47QY832QEP.jpg)

箱庭 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


# Page. 7

![Page Image](https://bcdn.docswell.com/page/KE4W21LYJ1.jpg)

箱庭 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


# Page. 8

![Page Image](https://bcdn.docswell.com/page/L71YMGLNJG.jpg)

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


# Page. 9

![Page Image](https://bcdn.docswell.com/page/G7WG3KQME2.jpg)

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


# Page. 10

![Page Image](https://bcdn.docswell.com/page/4JZLVZWME3.jpg)

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


# Page. 11

![Page Image](https://bcdn.docswell.com/page/YE6W5ZG5EV.jpg)

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


# Page. 12

![Page Image](https://bcdn.docswell.com/page/GE5MYWVGE4.jpg)

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


# Page. 13

![Page Image](https://bcdn.docswell.com/page/9729GQ3DJR.jpg)

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


# Page. 14

![Page Image](https://bcdn.docswell.com/page/DJY4VW1M7M.jpg)

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


# Page. 15

![Page Image](https://bcdn.docswell.com/page/V7NYM923E8.jpg)

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


# Page. 16

![Page Image](https://bcdn.docswell.com/page/YJ9PN21P73.jpg)

既存の分散シミュレーションとの比較
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


# Page. 17

![Page Image](https://bcdn.docswell.com/page/GJ8DK54XJD.jpg)

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


# Page. 18

![Page Image](https://bcdn.docswell.com/page/LJLMZY6NER.jpg)

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


# Page. 19

![Page Image](https://bcdn.docswell.com/page/47MYVN5Q7W.jpg)

新しい用語の整理
• 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


# Page. 20

![Page Image](https://bcdn.docswell.com/page/P7R92D3KE9.jpg)

単一オーナーの不変条件
状態の決定責任は常に一箇所に存在
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


# Page. 21

![Page Image](https://bcdn.docswell.com/page/PJXQD1457X.jpg)

箱庭アセット/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


# Page. 22

![Page Image](https://bcdn.docswell.com/page/3JK9X2ZRJD.jpg)

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


# Page. 23

![Page Image](https://bcdn.docswell.com/page/LE3W54DGE5.jpg)

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


# Page. 24

![Page Image](https://bcdn.docswell.com/page/8EDKDQPN7G.jpg)

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


# Page. 25

![Page Image](https://bcdn.docswell.com/page/V7PKXLNNJ8.jpg)

最新箱庭アーキテクチャ
[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


# Page. 26

![Page Image](https://bcdn.docswell.com/page/2JVVLQKYJQ.jpg)

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


# Page. 27

![Page Image](https://bcdn.docswell.com/page/5EGLXWQWJL.jpg)

箱庭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


# Page. 28

![Page Image](https://bcdn.docswell.com/page/4JQY83KQ7P.jpg)

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


# Page. 29

![Page Image](https://bcdn.docswell.com/page/K74W21PYE1.jpg)

箱庭コンダクタ
箱庭時刻の同期と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


# Page. 30

![Page Image](https://bcdn.docswell.com/page/LJ1YMG9NEG.jpg)

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


# Page. 31

![Page Image](https://bcdn.docswell.com/page/GJWG3KNM72.jpg)

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


# Page. 32

![Page Image](https://bcdn.docswell.com/page/4EZLVZ3M73.jpg)

箱庭 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


# Page. 33

![Page Image](https://bcdn.docswell.com/page/Y76W5ZX57V.jpg)

箱庭 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


# Page. 34

![Page Image](https://bcdn.docswell.com/page/G75MYWXG74.jpg)

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


# Page. 35

![Page Image](https://bcdn.docswell.com/page/9J29GQXDER.jpg)

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


# Page. 36

![Page Image](https://bcdn.docswell.com/page/DEY4VW8MJM.jpg)

最新箱庭のデモ（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


# Page. 37

![Page Image](https://bcdn.docswell.com/page/VJNYM9Q378.jpg)

37


# Page. 38

![Page Image](https://bcdn.docswell.com/page/YE9PN2DPJ3.jpg)

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


# Page. 39

![Page Image](https://bcdn.docswell.com/page/GE8DK53XED.jpg)

最新箱庭のデモ（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


# Page. 40

![Page Image](https://bcdn.docswell.com/page/LELMZYVN7R.jpg)

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


# Page. 41

![Page Image](https://bcdn.docswell.com/page/4JMYVNGQJW.jpg)

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


# Page. 42

![Page Image](https://bcdn.docswell.com/page/PJR92DZK79.jpg)

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


