TIME TO NEXT EXPERIMENT
RFR
Failure Reconstruction Engine
不具合調査を短く。価値検証を長く。
ロボット内部のデバイス通信から組込みLinux、LTE、クラウドまでのログを共通の時間軸で関連づけ、フィジカルAIに取り組む企業が次の実機検証へ戻るまでの時間を短縮する研究開発プロジェクトです。
RFRの公開サイトを見る ↗RFR
TIME TO NEXT EXPERIMENT
不具合調査を短く。価値検証を長く。
CHALLENGE
解決したいこと
ロボット開発では、通信仕様の確認、ログ取得の準備、障害の再現待ち、時刻合わせ、担当チーム間の調整に時間がかかり、本来の顧客価値を確かめる実機検証が止まることがあります。特に、機体からクラウドまでログの形式や時計が異なる場合、障害の原因範囲を絞ることが難しくなります。
APPROACH
現在のアプローチ
デバイス、ROS 2、Linux、モデム、LTE、通信、クラウド、復旧処理から得られる証拠を共通イベントへ正規化し、異なる時計をそろえてFailure Timelineとして再構成します。最初に観測された逸脱、根拠、不確かさ、不足している証拠を分けて示し、次に取得すべきログや確認項目へつなげます。
SYSTEM DIAGRAM
FAILURE RECONSTRUCTION
機体からクラウドまで、障害をひとつの時間軸で再構成
形式も時計も異なるログを共通イベントへ変換し、根拠を保ったまま原因範囲を絞ります。
デバイス
センサ／コントローラ
ロボット
ROS 2／組込みLinux
ネットワーク
モデム／LTE／通信
クラウド
API／サービス／復旧処理
正規化
共通イベントモデル
Rawログを保持し、時計をそろえる
FAILURE TIMELINE
逸脱 → 根拠 → 不確かさ
事実とMissing Evidenceを分ける
次の検証
次に取得するログ・実機試験
価値検証へ戻る時間を短縮
RESEARCH FLOW
研究・検証の流れ
- 01
Connect / 接続
通信を理解し、対象機器と必要な観測点をつなぎます。
- 02
Detect / 検出
異常に気づき、障害前後の証拠を失う前に残します。
- 03
Reconstruct / 再構成
異なる形式と時計を揃え、原因範囲を根拠で絞ります。
- 04
Continue / 継続
調査結果を次の価値ある実機試験につなげます。
CURRENT STAGE
現在の研究段階
現在は、原因と修正結果が判明しているモバイル通信障害1件を、手元にある3〜5種類のログから再構成するv0を起点として、Connectivity Failure Reconstruction Sprintと、既存機器の接続・無線化PoCを共同で検証しています。
公開情報について
本ページはRFR公開サイトで公開されている情報をもとに、invilabの自社研究開発テーマとして整理したものです。公開情報確認日：2026年8月10日
研究開発中のため、将来の製品・サービス提供や記載された機能の実装を保証するものではありません。