Applied Intuition の SDS が ADP を活用し、アクティブ セーフティ開発を加速させる方法

Applied Intuition のアクティブ セーフティおよび SDS (Self-Driving System) チームは、システム複雑性の増加、長期的な極端なケース、そして厳しいスケジュールの中で強化された規制など、顧客企業が直面している同様の課題に直面しており、これらに対応するために当社は自社開発ツールを活用しています。

このブログでは、従来のアクティブ セーフティ開発がなぜ遅く断片化していたのか、ADP (Applied Development Platform) がこれをどう変革するのか、そして当社の SDS チームがこのプラットフォームをどのように活用しているのかについて説明します。

なぜアクティブ セーフティの開発は遅く、断片化されているのか？

Euro NCAP 2026 は、より高い速度、夜間条件、より複雑な交差点、脆弱な道路利用者シナリオで衝突回避テストを拡大します。物理的な試験場は依然として重要ですが、路上走行テストだけでこれらすべてをカバーすることは非現実的です。したがって、これを実現するには統合されたシミュレーションおよびデータ プラットフォームが不可欠です。

分散されたワークフローが検証速度を低下させます

多くの自動緊急ブレーキ (AEB) および車線維持支援(LKA) プログラムは、断片化されたツールと引き継ぎプロセスに依存しています。

• トラック、試験場、車両で収集されたデータは、一貫性のない収集経路とパイプラインを通じて流入します。
• KPI 計算、分析、分類作業が、異なるチームが保有する複数のツールに分散されています。
• テスト結果のフィードバックループが機能担当者に伝わるまでに数週間かかる場合があります。

その影響は測定可能です。

ある都市型公共交通プログラムにおける実地テストキャンペーンでは、低速 AEB が歩行者を確実に回避することが示されました。しかし、非常に遅い歩行者 (歩行補助具使用者に類似した約0.5m/s) を対象とした後続のシミュレーションでは、シャトルが全く制動しない事実が明らかになりました。根本原因の分析はチームとツールに分散され、単一エンジニアのワークステーションで実施されました。数週間を要した末、認識システムが極めて低速な歩行者を静的障害物と分類した問題に起因することが判明しました。プログラムが分散化され、ローカルで実行されるツールに依存する場合、このような数週間に及ぶ検証ループは頻繁に発生します。

KPI のギャップは実際の成果を覆い隠します

ほとんどのチームは開発を導くために KPI を望みますが、大規模データセットに対する最新の指標は稀です。

• 異なるグループが一貫性のないツールと方法論で指標を計算
• 結果は主要なマイルストーン後に静的なレポートとして到着
• 分析はしばしば高コストなテストキャンペーン終了後にようやく開始

その結果、洞察が遅延し、データ収集は非効率的になります。

例えば、スウェーデンの冬季テストやオーストラリアの高温環境キャンペーンは数ヶ月前から計画され数週間実施されますが、分析はキャンペーン終了後に開始される場合があります。データ収集を集中させられた重要な発見が遅すぎて導き出され、追加出張の必要性とプログラム遅延が数ヶ月発生します。

AEB において、数千運転時間あたりの誤作動は主要な KPI です。目標値が 0 に近づくほど全てのイベントを分類する必要があり、新たなスタックリリースごとに代表的な運用設計領域 (ODD) データセットを基準に検証しなければなりません。分散型ツールでこれを実行することは、即座に主要な運用負担につながります。

構造化されていない分類作業は時間を浪費します

問題が検出されると、チームはしばしば次のような分類作業を行います。

• ログビューア、カスタムスクリプト、内部ツール、スプレッドシート間の切り替え
• メールやチャットによるスクリーンショットやログ抜粋の共有
• 所有権の変更や文脈の喪失による分析の再実行

その結果、問題解決が遅くなり、エラーが発生しやすくなり、知識の継続性が低下します。

オープンな再シミュレーションによる AEB 誤検知のモニタリングが代表的な事例です。チームは、走行データの収集、取り込み、大規模な再シミュレーション、KPI の計算、分類、回帰検証のプロセスを、多くの場合、排他的なレガシーシステムをまたいで連携させる必要があります。エンジニアはコアスタックの開発と承認に集中するよりも、複雑なインフラ運用に縛られることになります。

道路テストはロングテール現象を見逃します

道路およびトラックテストでは、頻度は低いものの安全上致命的となるシナリオを扱うことが困難です。

• 特定の地域や季節にのみ現れるアクター
• 悪天候または低視程条件
• 複雑な交差点または特異なインフラ

純粋な道路環境では、ムースのような大型動物の検知検証は困難です。接触頻度が低く、行動が多様で、条件が変化するためです。シミュレーションは、動物の行動、天候、交通を体系的に変化させることでこれらのギャップに対処できます。特に、現実世界の事象やニアミスを再利用可能なパラメータ化されたシナリオに変換できる場合に有用です。

ADP はアクティブ セーフティのワークフローをどのように変革しますか？

ADP (Applied Development Platform) は、データ、KPI、トリアージ、シミュレーションを単一プラットフォームに統合し、アクティブ セーフティ チームがツールの連携に時間を浪費せず、スタックの改善に集中できるようにします。

KPI から信号までの単一ワークフロー

ADP は単一環境で上位の性能指標と下位のセンサーデータを接続します。

1. トラック、道路、シミュレーション全体にわたる KPI (例：AEB 誤検知率、LKA 車線維持品質、NCAP 2026有効性スコア) から開始
2. 道路タイプ、環境、車両、ソフトウェアバージョンでフィルタリングし、性能低下のポイントを特定
3. KPI 異常値から正確な原因を究明するためのシーケンス分析
4. 同一 Web UI 内でセンサー信号、オブジェクトリスト、プランナー出力、作動コマンドをすべて検査

内部的に ADP を活用し、様々なシナリオとスタックバージョンにわたる NCAP 2026 AEB 効果性を監視し、大規模な実データセットに対するオープンループ再シミュレーションを通じて AEB 誤検知率を追跡します。これらのワークフローを単一プラットフォームで実行することで、KPI と基盤データビューを時間経過とともに一貫性と比較可能性を保ちます。

組み込みの分類構造

ADP は、任意の調査ではなく、構造化された分類フローを実装します。

• KPI 異常またはテスト失敗の検出
• 関連データセットおよびシーケンスの識別とグループ化
• 個々のシーケンスおよびフレームの検査と注釈の追加
• 明確なコンテキスト (データ、条件、スタックバージョン) による問題定義
• 解決までの所有権およびステータスの追跡

これにより重複作業が減り、トリアージがより予測可能になり、関連するシーンのライブラリが構築されます。AEB 誤検知モニタリングの場合、ADP は記録された大規模トラフィックログコレクションを処理し、ログ再生モードで AEB スタックを再シミュレートし、シナリオメタデータ、センサーデータ、KPI 寄与度など全体コンテキストと共に各活性化事例を自動露出することで効率的なトライジを支援します。

実データと緊密に連携したシミュレーション

ADP はシミュレーションを実際の現場発見事項と直接結びつけます。

1. 車両またはトラックデータからの興味深い事象またはニアミス事故の検出
2. 主体、軌跡、環境を含むシナリオ抽出
3. パラメータ化されたシナリオまたはシナリオ群への変換
4. シミュレーションでの変形実行によるシステム動作の探索と改善点のテスト
5. 有望な修正案をシミュレーションで検証した後、適切な場合には実路上で確認

このループは KPI モニタリングやトリアージと同じプラットフォーム上で実行されるため、シミュレーションは独立した単発作業ではありません。例えば、冬季のムース検知ニアミス事故は、次の実路テストキャンペーン前に様々な速度、照明、気象条件で再現されるシナリオテンプレートとなり得ます。

Applied Intuition の SDS チームは ADP をどのように活用していますか？

Applied Intuition の SDS チームは、独自のアクティブセーフティ機能を開発するために毎日 ADP を使用し、プラットフォームの内部顧客としての役割を果たしています。

生産環境ツールとしての SDS 構築

顧客に提供するのと同じ生産用 ADP プラットフォーム上で SDS を運用します。別途の内部プロトタイプスタックは存在しません。実際には二つの主要な設定を使用しています。

• 大規模データ収集管理および実/合成シナリオに対する大規模シミュレーション実行のための専用ADP サーバー
• 新機能および修正事項の迅速なテーブル上テストのための開発者マシンのローカル ADP インスタンス

両環境は同一の UI とワークフローを共有するため、エンジニアは迅速なローカル実験から大規模評価へシームレスに移行でき、高頻度開発サイクルを支援します。エンジニアが依存するデータ収集、KPI 計算、トリアージ、シミュレーションといった同一機能群が OEM および Tier 1 サプライヤーにも提供されます。これは多くのツールが主にデモや単発プロジェクト向けに構築される分野では珍しい事例です。

AEB によるエンドツーエンド事例

AEB 開発ワークフローがこれをどのように実現するかを示します。

• ローカル反復：エンジニアは、Euro NCAP および FMVSS シナリオのサブセットを活用して、ローカルで新しい AEB 機能を設計およびテストし、回帰現象を早期に検出します。
• 大規模シミュレーション：安定化された変更は、ADP サーバー上で大規模な合成および実データセットを通じて評価され、AEB KPI が推定されます。
• 誤作動率推定：ADP は大規模な記録済み交通ログセットで AEB スタックを再シミュレーションし、誤作動アクティベーション事例を集計して現実的な誤作動率を算出します。
• NCAP および規制スコア：ADP 内の Euro NCAPおよび FMVSS テストスイートで AEB を再実行し、スコアボードは現行システムの NCAP スコア、星評価、規制合格/不合格結果を表示します。
• 構造化されたトリアージ：誤作動の発生や特定のシナリオでの性能低下が発生した場合、開発者はADP 内で個々のシミュレーションログ (内部信号、オブジェクト軌跡、プランナー決定、アクチュエーター指令) をレビューし、次の反復作業を推進します。

ローカルテストから大規模な再シミュレーション、KPI レビュー、トリアージに至るまで、このループは主に ADP を通じて実行されるため、SDS エンジニアはすべての意味のある変更について迅速かつ一貫したフィードバックを得られます。これはまた、SDS 作業によるすべての改善点 (例：強化されたコラボレーションやより効率的なNCAP ワークフロー) が、同じプラットフォームを使用する顧客チームに即座に提供されることを意味します。

アクティブ セーフティ分野で一緒に働きませんか？

アクティブ セーフティまたは ADAS システムを構築中で、検証ループの遅延、KPI のギャップ、トリアージのボトルネック、ロングテールカバレッジなどの課題を抱えているなら、ADP がどのように役立つか詳しくご覧ください。

当社の SDS チームがプラットフォームを活用する方法を確認し、同様のワークフローが御社の開発および検証プロセスにどのように適用できるかご覧いただけます。

ツール中心のワークフローと大規模なアクティブセーフティ開発に情熱を持つエンジニアの方、技術的限界を超えることに意欲的な方々との対話を常に歓迎します。