Technology / 技術詳細

機体内部の通信から、Linux、LTE、クラウドまでを同じ時間軸へ。

RFRは、取得可能な各レイヤーの証拠をSemantic Eventへ正規化し、First Observed Deviation、Evidence Chain、不確かさ、Missing EvidenceをFailure Timelineへ再構成します。

Product path / 構想と現在地

Device-to-Cloud Failure Reconstructionから始め、必要な観測点とAdapterを製品化します。

トップページは製品ビジョン、このページは現在の実装順序を示します。

現在機能と将来設計を混ぜず、各段階で安全性と価値を検証します。

Product Vision / 製品ビジョン

Device-to-Cloud Failure Reconstruction

デバイス、ROS 2、Linux、モデム、LTE、Transport、クラウド、復旧処理を共通の意味と時間軸へ接続します。

Current v0 / 現在

3〜5ログ + Manual Anchor + Failure Clip + Evidence Chain

アプリ、Linux、モデム、接続状態、クラウドなど手元にあるログから、最初の逸脱と不足観測を特定します。

Next PoC / 次の共同検証

Ingest Agent → Connectivity Adapter → Clip Hold → Reconstruction → Pattern Register

繰り返し必要になるログ変換、リングバッファ制御、BLE観測点、再発検知ルールを段階的に製品化します。

名称役割
RFR Ingest AgentROS 2、アプリ、Linux、ネットワーク、モデム、クラウド通信、リングバッファをread-onlyで取得する。
RFR Tap / Bridge NodeLinuxの外側にあるUART・RS-485実通信を観測・正規化し、必要時のみ能動Bridgeとして動作する。
RFR Edge GatewayBLE Mesh管理、Direct BLE回収、Clock Coordinator、Failure Clip回収を担い、必要時のみEthernet・Wi‑Fi・LTEを追加する。
RFR Reconstruction CoreSemantic Event正規化、Clock Mapping、異常検知、Failure Timeline、Evidence Chain、Pattern登録を担う。

BLE architecture / 制御プレーンとデータプレーン

各NodeはBLE-only。Rawログ転送と外部接続を分離します。

BLE MeshへRawログを流し続けません。Rawの正本はNode内へ残し、必要なFailure ClipだけをDirect BLEで回収します。

Wi‑FiとLTEはEdge Gatewayのオプションです。LTEを搭載した構成では、外部接続手段であると同時に、モデム状態からクラウド応答までの観測対象になります。

RFR Node

BLE-only + local Raw store

UART / RS-485 Capture、リングバッファ、時刻情報、欠落カウンタをNode内へ保持します。Wi‑Fi・LTEは搭載しません。

BLE Mesh

Control & notification plane

node discovery、health、anomaly notification、configuration、time mapping、clip retrieval requestを扱います。

Direct BLE

Selected clip transfer

Gatewayが対象Nodeへ直接接続し、event indexで指定した区間だけを取得します。再送と転送完全性を確認します。

Edge Gateway

BLE collection + optional uplink

Direct BLE回収、ローカル解析、RFR Coreへの取り込みを担います。クラウド接続が必要な段階でWi‑Fi / LTEを追加します。

Failure Clip回収フロー

Nodeで異常を検出 → Rawをローカル保持 → BLE Meshで異常通知 → Gatewayが対象NodeへDirect BLE接続 → 必要区間だけ回収 → RFR Coreで再構成。

Gatewayが外部へ接続できない場合も、NodeのRawログとGatewayの回収結果はローカルに残ります。

Common Connectivity Model / 接続状態の共通イベント

モデム固有通知を、Device-to-Cloud Evidenceへ正規化します。

AIはデータシートやATコマンドマニュアルからAdapter候補を生成します。

人間が意味と変換品質を検証した後は、AIを通さない決定論的Adapterとして実行します。

Connectivity state

  • Application Transaction: request_started / timeout / retry
  • Modem State: ready / resetting / unavailable
  • Network Registration: searching / registered / denied / lost
  • Data Session: activating / active / degraded / deactivated
  • Signal Condition: strength / quality / cell_id / network_mode

Transport & Recovery

  • DNS: started / resolved / failed
  • TCP / TLS: connected / established / timeout
  • MQTT / HTTP: connected / response / error
  • Recovery: reconnect / modem_reset / interface_restart
  • Evidence: uncertainty / missing operator logs / next capture

Product concept / 製品コンセプト

v0は、解決済みのモバイル通信障害1件を再構成する縦切りPoCです。

入口は、手元に残っている3〜5データソースです。ROS 2・アプリ、Linux、モデムAT、LTE状態、Transport、クラウド、電源ログを対象にします。

Rawイベントにはtrace_idを必須にしません。transaction_id、clip_id、derived traceは、取り込み後の再構成で関連付けます。

時刻整列は自動推定から始めません。人間がManual Anchorを打ち、レーンのoffsetやdriftを調整します。

順序が不確かなイベントは、順序不確定として明示します。RFRは分からないものを分からないと表示します。

専用Tap、BLE Node、Gatewayは後段です。まず既存ログでDevice-to-Cloud Failure Timelineを作り、どの観測点とAdapterが繰り返し必要になるかを確認します。

01

対象障害を絞る

原因と修正結果が分かっているLTE・モデム・クラウド関連の障害1件。機体側と外部側のログが別時計で残るケースを扱います

02

入口を3〜5ログに絞る

アプリ、Linux、モデム、接続状態、クラウドから残っているものを持ち込みます。最初から全レイヤーや専用ハードを前提にしません

03

作業を絞る

持ち込みログ、手動アンカー、Failure Clip、Raw確認、AI要約、根拠イベントジャンプまでを完成させます

MVP scope / 最初に作る範囲

MVP v0では、汎用基盤を作りません

1つの実失敗を、従来より速く解くことに集中します。

対象は、機体からクラウドまでのモバイル通信障害です。

持ち込みログ、手動アンカー、Failure Clip、Raw確認、AI要約、根拠イベントジャンプまでを縦切りで完成させます。

trigger() APIやSDKは、意図イベントを一級市民化する後段レイヤーです。

MVP v0でやる

  • Import panelでMCAP、CSV、JSONL、journal、AT log、cloud access logを取り込む
  • Multi-lane timelineでROS、Linux、Modem、Connectivity、Cloud、Power、AI analysisを並べる
  • Manual Anchorで、異なる時計のApplication、Modem、Cloudイベントを同じ瞬間へ対応付ける
  • Lane offsetをドラッグし、アンカー2点からscale + offsetを推定する
  • 順序不確定な近接イベントを、前後関係を断定せずに表示する
  • unknownとnullを区別し、時刻精度が不明なイベントを別表示にする
  • 範囲選択、operator marker、deterministic anomalyからFailure Clipを作る
  • Evidence inspectorでRaw、decoded、AI summary、根拠イベントジャンプを確認する
  • ソフトウェア側も非侵襲にし、tail/import/ROS mirrorはread-onlyで扱う

MVP v0ではやらない

  • 汎用Observability基盤の完成
  • SDK-firstの導入
  • trace_idをRawイベントに必須化すること
  • 共通参照のないログの完全自動時刻同期
  • 市販タップを量産品質のCapture Deviceだと見せること
  • 専用Capture Nodeの量産設計
  • C++ SDK
  • AIによる自動コマンド送信

Phase 0.5 / Commodity Tap Kit

専用Capture Deviceの前に、市販アダプタで低レイヤログを取ります

目的は量産品質ではありません。

低レイヤログがあると、本当に原因特定が速くなるかを即日で検証することです。

Adapter TXは接続せず、RX専用で観測します。

ホスト到着時刻なので、高精度タイムスタンプとは呼びません。

UART tap / RX専用

2本のTXを、2つのUSB-UART RXで見る

Target Controller TX  -> Adapter 1 RX
Target Device TX      -> Adapter 2 RX
GND                   -> Common GND
Adapter TX            -> Not connected
  • Adapter TXは絶対につながない
  • 1.8V / 3.3V / 5Vのレベルを確認する
  • RS-232レベルをTTL UARTへ直結しない
  • 安全系・高電圧系・本番設備では使わない

RS-485 tap / 受信専用

A/Bラインを、送信無効のUSB-RS485で観測する

RS-485 A/B  -> Adapter A/B
Adapter TX  -> Disabled
DE          -> Disabled
RE          -> Receive enabled
Termination -> Usually OFF
  • バスに影響しないことを最優先にする
  • DE無効固定、またはreceive-only構成を選ぶ
  • 終端、バイアス、自動送信制御の有無を確認する
  • 絶縁なしアダプタは実験用と割り切る
市販タップ 安い、早い。時刻品質、絶縁、リングバッファ、欠落検出は弱い。
RFR Wired Tap read-only保証、ハードウェアタイムスタンプ、絶縁、リングバッファ、欠落検出を担う。

System architecture / システム構成

既存ログを取り込み、人間アンカーで整列し、Failure Clipに変換します

Rawイベントは、キャプチャ時点でtrace_idを知らなくて構いません。

Clip作成後にclip_id、episode_id、derived_trace_idを付与します。

v0の時刻整列は、まず人間アンカーとlane offsetから始めます。

時刻精度が分からないイベントはunknownとして扱い、nullや±2msと同じ見た目にしません。

RFR Ingest Agentは、制御ループをブロックしないread-onlyの非侵襲設計にします。

Level 0 File import

UART dump、CSV、JSONL、MCAP / rosbag2

Level 2 Manual alignment

pin event A to B、lane drag、offset、drift

Level 2 Clip builder

範囲選択、marker、deterministic anomaly

Evidence Failure Timeline

Raw確認、AI要約、根拠ジャンプ、順序不確定

ソフトウェア側も非侵襲にします

RFR Ingest Agentとread-onlyのROS mirrorは、制御ループを止めません。 Ingest Agentが落ちてもロボット側を止めず、同期I/Oを制御スレッドに入れません。

ローカルスプール、dropped_event_count、非同期送信を前提にします。 importはread-only、ROS topic mirrorはsubscribeのみです。能動的なRFR Bridgeは別コンポーネントとして、安全条件とBYPASS挙動を対象機器ごとに検証します。

Capture Device / 後段の低レイヤ補完

公開LPではMCU型番より、何を安全に取るかを示します。

v0の主役は、実ログをEvidence Bundleへ変換することです。

3件中2件で低レイヤCapture品質が問題になったら、RFR Wired Tapを設計します。

位置づけ Platform本体ではなく、RFR Coreへ低レイヤイベントを流し込むCapture Device。
市販タップとの差分 read-only保証、絶縁、リングバッファ、欠落検出、ハードウェアタイムスタンプを提供する。
優先順位 Current v0で意味と不足観測を特定し、Next PoCでOBSERVE、Shadow Translation、有線Bridge、Direct BLEエミュレーション、BLE Node / Gatewayの順に検証する。
UART / RS-485 read-only、高インピーダンス、target_rx / target_txとして方向を記録。既存通信を壊さない。
Node無線 BLEのみ。Wi‑FiやLTEは搭載せず、Rawログの正本をローカル保存する。
BLE Mesh ノード発見、状態通知、異常通知、設定配布、時刻対応付け、回収要求に限定する。Rawログ転送には使わない。
Direct BLE Gatewayが対象Nodeから必要区間だけを回収する。Failure Clipと転送完全性を管理する。
Gateway uplink 外部接続が必要になった段階で、Edge GatewayへだけWi‑FiまたはLTEを追加する。
Marker manual markerを用意し、ロボットが自分で失敗を認識できないケースを人間がClip化できるようにする。

AI Debugger / 読み取り専用の解析者

AIには、勝手に機器を操作させません。

MVPのAIはread-onlyです。

コマンド送信や設定変更は行いません。

CRCエラー、タイムアウト、フレーミングエラー、応答遅延などは、まずルールベースで確定検出します。

AIはその結果をもとに、原因候補、根拠、次に確認すべきことを整理します。

AIの役割は、ログの代わりに判断することではありません。

人間がRawログを確認しやすくすることです。

  1. Raw bytes / 生の通信ログ
  2. Frame detection / フレーム境界の検出
  3. Protocol decoder / プロトコルの読み解き
  4. Rule-based anomaly detection / ルールベースの異常検出
  5. Structured event timeline / 構造化された時系列
  6. AI summarization / 根拠付きの要約

Design principles / 設計思想

勝つための優先順位を間違えない。

  1. 01実ログと実機から通信の意味を確認する
  2. 02能動接続の前にOBSERVEで受動観測する
  3. 03Shadow Translationで変換結果を人間が承認する
  4. 04Raw通信を一次情報として必ず残す
  5. 05順序不確定と時刻unknownを隠さない
  6. 06BLE MeshへRawログを流さず、Direct BLEで必要区間だけ回収する
  7. 07Wi‑Fi・LTEはNodeへ載せず、必要時のみGatewayへ追加する
  8. 08AIはread-onlyで、Evidence Chainを読む補助にする