稼働時間の方程式：なぜ車両プラットフォームはクラウドを待てないのか

これは『アップタイムの方程式』の第3部です。 第1部 では車両のコンテキストについて、そして 第2部 では、ハードウェアとソフトウェアのトレードオフについて取り上げました。このパートでは、処理をどこで実行すべきかについて解説します。

長距離トラックが、携帯電話の電波が届かない区間の高速道路を走行している。その区間のどこかで、90秒間にわたり断続的な電気的障害が発生し、その後解消される。検知をクラウドに依存している場合、次の2つのうちのいずれかの事態が生じる。その事象が見逃されるか、あるいは関連する信号がすでに上書きされた後に、遅れてスナップショットが届くことになる。次に同じ問題が発生した際、その原因となった状況の記録が残っていない整備工場で発生する可能性がある。

これは、以下で説明されている「リドライブ問題」のフィールド版である。 『エージェントループ』で説明されている「リドライブ問題」の現場版です。商用車では、その運行場所や方法の性質上、この現象がより頻繁に発生します。

接続性は当然のことではない

サービスエリアマップは楽観的だ。ある 2019年のFCCによる実地調査では、現場担当者が12州で1万マイル近くにわたり、24,649回のドライブテストを実施した。テストのうち、通信事業者のマップが予測したダウンロード速度に達したのはわずか62.3％に過ぎなかった。2019年以降、ネットワークは改善されているが、そこから得られる教訓は変わらない。つまり、通信エリアを示すマップがあるからといって、故障が発生した瞬間にトラックが確実に電波を受信できるとは限らないのだ。 鉱山、農場、建設現場、港湾などのオフハイウェイ機器は、通信エリア計画担当者が優先順位をほとんど付けない場所で稼働している。車両管理部門はすでにこの状況を踏まえた計画を立てている。運転手はヤードに到着するまでログの送信を待ち、技術者はトラックが戻ってきた際に手作業でデータを抽出する。また、走行中に通信が途絶えたトラックは、警告ではなく「通常のこと」として扱われる。こうした回避策はいずれも稼働時間を犠牲にし、高速道路の何もない区間で発生する90秒間の通信障害を検知することはできない。

こうした不確実性により、オフラインでの運用は単なる代替手段ではなく、設計上の要件となっている。マッキンゼーが実施した 自動車分野におけるエッジAI に関する調査では、回答者の39％が、すべてのAI ユースケースにおける主要要件として「オフラインでの可用性」を挙げ、これは「低遅延」（35％）や「データのプライバシーとセキュリティ」（20％）を上回りました。ネットワークデータコストを挙げたのはわずか6％でした。エッジ導入の根拠は、通信費の問題というよりも、むしろクラウドでは把握できない要素にあるのです。

データ量：問題は信号対雑音比であり、データ通信料ではない

商用車のネットワークは、絶えずデータを生成しています。1台の SAE J1939/14 バスは最大500 kbit/sで動作可能であり、多くの大型トラックでは複数のバスが使用されています。また、新しいプラットフォームではオートモーティブ・イーサネットが追加されており、その多くはADASや安全システム向けのカメラ映像を伝送しています。1日の走行全体を通じて見れば、送信する価値のあるデータ量はごくわずかであり、その大部分は単に「異常がなかった」ことを確認するだけのものです。

「 「Agentic Loop」 で概説されているように、常時ロギングは「セルラーネットワーク経由での送信コストが高く、保存コストが高く、処理コストも高い」ものです。その代替案として、どのデータが重要かを車両側で判断するという方法があります：

• イベント駆動型キャプチャ。 常にすべての信号を記録するのではなく、イベントの前後のみを記録します。Fastlane™ Edge Smart Triggersを使用すると、例えば、車両に搭載された軽量な異常検知モデルが、エンジンが正常範囲外で稼働しているなどの異常な挙動を検出した場合にのみ、Fastlane™ Collector ポリシーを起動します。これにより、車両は連続的な信号ストリームではなく、異常イベント前後の信号のみをキャプチャします。
• 車載圧縮。 Fastlane™ Collector 時系列圧縮により、データペイロードサイズが最大28倍縮小されると述べている。
• 車載履歴。 車両に搭載された時系列データベースには、直近数週間から数ヶ月分の信号履歴が保存されています。デッドゾーンで障害が発生した場合でも、トラックが再接続した際にはそのコンテキストが保持されているため、エンジニアは障害が再発するのを待つことなく、必要な期間のデータを正確に抽出することができます。
• アップロード前のフィルタリング。 生のデータストリームではなく、要約された関連性の高い結果を送信します。ある あるパートナー企業の事例 では、車載侵入検知において、ローカルで処理を行い、関連性の高いアラートのみをアップロードすることで、クラウドコストを60％削減できた。

遅延：待てない決断もある

コンポーネントの保護、システムの動作調整、ドライバーへの警告、あるいはサイバー侵入の可能性の検知といった一部の処理は、数秒以内に行われる必要があります。そのため、こうした処理を行う場として車両が自然な選択肢となりますが、インテリジェンスをどこで実行すべきかは、レイテンシだけで決まるわけではありません。マッキンゼーは、エッジ処理が必ずしも決定的なレイテンシの優位性をもたらすわけではないと指摘しています。多くの診断ユースケースにおいて、ミリ秒単位の差よりも、可用性やコンテキストの方が重要となるからです。

とはいえ、クラウドの重要性が薄れるわけではありません。クラウドは、単一の車両では不可能な役割を果たしているのです：

• 全車両を対象としたパターンの検出。 ある1台のトラックではノイズのように見える故障モードが、数千台規模の車両全体では明らかな問題となる場合があります。
• 根本原因の調査。 車両データと技術文書、整備履歴、過去の事例を統合します。 Fastlane™ InsightAI を活用し、クラウド上でこれらの情報源を関連付け、考えられる根本原因を提示します。
• モデルの学習と検証。 ここでは、エッジで捕捉されたコンテキスト豊富なイベントを利用します。
• 配布。 更新されたモデルおよび回収ポリシーは、無線経由で車両に配信されます。

エッジが検知・取得を行い、クラウドが推論・学習を行い、その後、エッジがクラウドが学習した内容に基づいて動作します。 Fastlane™ Edge このシステムは、そのループを中核として構築されています。車両上で異常検知を実行し、クラウドが学習するにつれて無線経由で更新されたモデルを受信します。エッジ側でインテリジェンスを実行することで、ネットワーク接続への依存度を低減しつつ、車両群全体での学習を通じて、すでに走行中の車両の性能を継続的に向上させることができます。

一線を引く

役立つルール：データと締め切りがある場所に仕事を置くこと。

ある決定が、その瞬間の1台の車両のデータに依存する場合は、その決定は車両側で行うべきです。一方、一定期間にわたる多数の車両のデータに依存する場合は、クラウド側で行うべきです。車両側でコンテキスト情報を取得することは、混在する車両群の運用にも役立ちます。ソース側で、次のような共有信号定義を用いて構造化されている場合、 COVESA VSSのような共有信号定義を用いてソース側で構造化されていれば、どのブランドからでも同じ形式でフリートのテレマティクスプロバイダーに送信できます。また、市場予測によれば、OEM各社はこのモデルに投資を進めているようです。 GM Insights の推計によると、2025年には商用車が自動車エッジコンピューティング市場の35億9000万ドルを占め、年間約22％の成長率を示すとされています。

エッジが適切なコンテキストを捕捉すると、そのデータはAI の原料となり、単に障害を報告するだけでなく、障害を予測できるようになります。第4部では、この点について詳しく解説します。

結論： 商用車には、接続の両端にインテリジェンスが必要です。車両側は、検知、状況の把握、および時間的制約のあるアクションを処理します。 クラウドは、車両群全体にわたる学習を担当する。推奨事項：これらの処理はデフォルトで車両に割り当て、1台のトラック以上のデータが必要な処理のみをクラウドに任せること。最初からこれら2つを1つのループとして設計し、クラウドで学習されたモデルが、データを収集したトラックへとフィードバックされるようにする。トラックが検知できなかった不具合は、再び発生することになり、そのたびに稼働時間が失われることになる。