共有の車載ランタイムにより、どのモデルを常時アクティブに保ち、どのモデルを動作条件に応じてのみ実行するかを管理できます
商用車は、AI の機能が拡大するにつれてリソースの問題に直面しています。すべてのモデルを常時稼働させると、有限な演算能力やメモリへの負荷が増大し、新機能の統合、検証、運用が困難になります。アーキテクチャ上の課題は、車両で利用可能なリソースの範囲内で、いかにしてより高度な知能機能をサポートするかということです。
モデルが1つ追加されるごとに、CPUやアクセラレータの処理能力、メモリ、統合作業、および検証が必要になる場合があります。しかし、診断イベントやサービスワークフローの際に必要となるモデルであっても、すべての走行中に実行し続ける必要性はほとんどないでしょう。その機能が不要な場合でもモデルをアクティブな状態に維持し続けると、実行リソースを不必要に消費することになります。
メーカーにとって、これは初期生産の段階をはるかに超えた設計上の課題をもたらしています。商用車は長いライフサイクルにわたって稼働しますが、『FleetOwner』誌は次のように報じています。「フリート事業者がこれほど古い車両を運用するのは、10年以上ぶりのことだ。」と報じている。製造時に搭載される演算能力やメモリ容量は概ね固定されているにもかかわらず、それら上で動作するソフトウェアやAI に対する期待は高まり続けている。エンジニアリングチームは、新しいワークロードを既存の機能とどのように統合するか、またフリート全体でそれらをどのように展開、更新、監視するかを決定しなければならない。
運用担当者やサービスチームにとっても、データには同様の制約が見られます。ストレージ、帯域幅、接続性の制約により、クラウドへ転送できるテレメトリの量には限界があり、大量のデータを収集すると、チームは診断に重要なイベントやシグナルを探すのに手間取ることになります。このトレードオフは避けがたいものです。つまり、すべてをクラウドに送信してコストとノイズを許容するか、送信量を減らして重要なイベントを見逃すリスクを負うかのどちらかです。
どちらの問題も、 同じ答えを導き出していますを示唆しています。それは、知能を車両側に移し、個別の常時稼働モデル群としてではなく、共有された車両インフラとして管理することです。共通のランタイムは、モデル群を管理し、各機能の要件に応じて実行リソースを割り当てることができます。
デプロイと実行を分離する
重要な考え方は、「デプロイ済み」と「実行中」を切り離すことです。車両上でモデルを利用可能にしておくことと、そのモデルを実行することは、別々の判断事項となります。デプロイ済みのモデルは依然としてストレージを占有しますが、その実行は運用上のニーズに応じて管理することができます。
この区別により、2つのカテゴリーのエッジインテリジェンスが共存することが可能になります。パーシステント・インテリジェンスには、継続的な機能や安全上重要な機能をサポートするために常時稼働し続けなければならないモデルが含まれます。パーシステント・インテリジェンスの例としては、走行中にカメラ映像を処理し、衝突回避のために車両、歩行者、自転車を識別するADASの道路物体検出モデルが挙げられます。
オンデマンド・インテリジェンスには、車両の状況や運用条件に応じて必要となった場合にのみ作動するモデルが含まれます。オンデマンド・インテリジェンスの例としては、充電中や整備工場での整備中に作動し、バッテリーの劣化を評価してメンテナンスの必要性を通知するバッテリー状態評価モデルが挙げられます。同じハードウェア上でこれら両方をサポートするには、中断できない機能を妨げることなく、何が、いつ、どのリソースを使って実行されるかを決定する仕組みが必要です。
共有の車載ランタイムが、こうした判断を行うことができます。このランタイムは、デプロイ、有効化、無効化、モデルバージョン、車両信号へのアクセス、出力、モニタリングを管理すると同時に、各機能の要件に応じてCPU、メモリ、その他のリソースを割り当てることができます。
こうした決定は、検証やリソースの可用性など、各機能の要件を尊重したものでなければなりません。オンデマンド実行によって、統合作業や検証作業が不要になるわけではありません。これは、同時に実行する必要のないワークロードを管理するための手段を提供するものです。
モデルの実行タイミングは、車両の状況に基づいて決定する
車両の信号、診断イベント、動作モード、地理情報、サービスコンテキスト、およびその他のモデル出力は、アクティベーションの入力情報となり得ます。車両の状態がトリガーとなり、プラットフォームがモデルをアクティブ化し、モデルがタスクを実行し、タスクが完了するとプラットフォームがモデルを非アクティブ化します。モデルは、その機能が必要とされる間のみリソースを消費します。
アクティブ化されたモデルは、永続的な関数と同じリソースを競合して使用するため、これを実用化するには、CPUやRAMの使用状況、ストレージ、モデルのフットプリント、および同時実行中のモデルに関する可視性が必要です。また、エンジニアリングチームや運用チームは、フリート全体のデプロイ状況（何がインストールされているか、何が実行されているか、利用可能なリソースで要求されたワークロードに対応できるかどうか）を把握する必要があります。
共有のオーケストレーション層があれば、アプリケーションごとに個別のアーキテクチャを用意することなく、さまざまなアプリケーションを一貫して管理することができます。これには、リモート診断、エッジログ分析、構成監視、サービスモードやショップモード、モデル評価、および特定のエンジニアリングワークフローなどが含まれ、それぞれに異なる実行要件があります。
局所的に検出し、選択的に収集する
車両データの収集例を見ると、このアーキテクチャが実際にどのような変化をもたらすかがわかります。クラウド分析を中心としたワークフローでは、チームはデータを収集し、アップロードして、異常を検出し、注目すべき事象を特定し、関連するシグナルを抽出した上で、問題を診断します。
エッジインテリジェントなワークフローにより、この一連の流れが変わります。つまり、ローカルで異常を検知し、対象を絞ったデータ収集をトリガーし、関連するコンテキストをアップロードして、診断を行うという流れです。どのデータが重要かという判断は、今や車両側で行えるようになりました。
Sonatus’sFastlane™ Edge 「スマートトリガー」機能はその具体的な一例です。スマートトリガーは、車載エッジランタイム上で実行されているAI モデルと Fastlane™ Collectorを連携させます。エッジ側にある軽量な異常検知モデルや数学関数により、エンジンの動作閾値を監視できます。異常状態を検知すると、そのイベントに関連するエンジン信号を捕捉する Fastlane Collector ポリシーをトリガーし、そのイベントに関連するエンジン信号をキャプチャします。ターゲットを絞ったデータ収集は、エンジンの異常が検出された場合にのみ行われます。
このアプローチにより、より関連性の高い診断データセットを生成できるほか、車両からクラウドへの不要なデータ転送や手動によるログ検索を削減できます。接続リソースやストレージの使用効率の向上、あるいは調査時間の短縮につながるかどうかは、検知の精度やデータ収集方針によって異なります。
結局のところ、アーキテクチャ上のより広範な意味合いとしては、デプロイ、実行、リソース、およびライフサイクル管理を一体として考慮する必要があるということです。車両は、インストールされたすべてのモデルを常時稼働させる必要なく、拡大し続けるAI の機能ポートフォリオをサポートすることができます。エッジAI は、インテリジェンスが管理対象の車両機能となった際に、それに応じて拡張されます。