本稿は、KPMGコンサルティングの「Automotive Intelligence」チームによるリレー連載です。
自動車は「走るコンピュータ」へと進化し、今やSDVという新たなステージに突入しています。そこで、「SDVの本質を考える」と題し、さまざまな切り口からSDVについての考察をしていきます。
第2回では、SDVが直面する3つの課題と、ユーザーからの「期待値の設計」について解説します。
Software-Defined技術の共通点とSDVの課題
通信・ネットワーク・ストレージの分野では、これまで専用ハードウェアで担っていた機能を、汎用ハードウェアとソフトウェアの組み合わせに置き換えることで、運用コストと設備投資の両方を削減してきました。
たとえば、Software-Defined Radio（以下、SDR）は無線機能をソフトウェアで切り替え可能にし、Software-Defined Network（以下、SDN）はネットワークの制御プレーンを開放して、通信の流れをソフトウェアで制御できるようにしました。さらに、Software-Defined Storage（以下、SDS）ではストレージを仮想化し、容量をモジュール単位で柔軟に束ねることが可能になりました。
これらに共通しているのは、それぞれの機能を分けて、外部から柔軟に操作できるようになったことです。これにより、システムが複雑になっても、ソフトウェア側でうまく調整して対応できるようになりました。
その結果、現場での改善やアップデートが日常的に行えるようになり、製品やサービスを提供する企業同士の連携も、共通のルールや仕組み（プロトコルやAPI）を使って、より速くスムーズに進むようになったのです。
【図表1】
出所：KPMG作成
一方でSoftware-Defined Vehicle（以下、SDV）は、同じ「ソフトウェアで機能を柔軟に制御する」という考え方を持ちながらも、決定的に異なる課題に直面しています。
その1つが、リアルタイム性と安全性の両立です。自動車の中核となる機能は、ほんのわずかな遅れ（千分の1秒単位）でも事故につながる可能性があるため、非常に速く、かつ確実に動作することが求められます。こうした性能は、ISO 26262やISO/SAE 21434といった国際的な安全基準によって厳しく定められています。
また、システムの構成を柔軟にするために機能を分けてつなげるほど、最悪の場合にどれだけ遅れるかを予測・検証するのが難しくなるという問題もあります。
たとえば、SDNのようなネットワーク技術では、「多少遅れても正しく通信できれば問題ない」場面が多くあります。しかしSDVでは、「必ず間に合う」ことを常に証明し続けなければならないのです。
【図表2】
出所：KPMG作成
次に挙げられる課題は、ハードウェアの更新ペースがソフトウェアの進化の速さに追いつかないという点です。
車に搭載されるセンサーやアクチュエーター（動きを制御する装置）、電源まわりの部品は、一度仕様が決まると長期間変更が難しくなります。しかも、これらが誤作動した場合には、すぐに人命に関わるリスクにつながるため、非常に厳しい安全要件が求められます。
たとえば、SDSのバックアップ構成やネットワークの再接続のように、「数秒待てば復旧する」といった対応は、車載システムではほとんど許されません。
そのため、SDVにおけるOTA（Over-the-Air：遠隔でのソフトウェア更新）は、機能を追加する便利な手段である一方で、安全性の再確認を必要とする“負担”にもなるのです。ソフトウェアのたった一行の変更でも、車種ごとの検証や、国の審査にまで影響が及ぶ可能性があります。
結果として、クラウド（インターネット側）とエッジ（車両側）の両方で、「安全であることを証明できる仕組み」が欠かせなくなっているのです。
3つ目の課題は、システム全体の設計思想の重心が、他の分野とは大きく異なるという点です。
SDR、SDNそしてSDSなどの分野では、「通信やデータ処理は汎用的な仕組みで十分」という共通認識があり、オープンな技術や標準的なハードウェア（x86など）を中心にエコシステムが構築されてきました。
しかしSDVの場合、車の制御に関わる計算処理が、車載コンピュータ（ECU）に非常に近い場所で行われる必要があるため、事情が大きく異なります。センサーの情報を統合する処理（センサーフュージョン）や、ブレーキ・アクセルなどの制御（アクチュエーター制御）など、物理的な動きに密接に関わる領域が多数存在するのです。
こうした領域では、機能をざっくりまとめすぎるとリアルタイム性（即時性）が保証できなくなり、逆に細かく分けすぎると検証作業が膨大になってしまうというジレンマがあります。
そのため、現実的な設計方針としては、システム全体を段階的に抽象化しながら、安全性が特に重要な領域（パワートレインやブレーキなど）と、サービスの柔軟性が求められる領域（インフォテインメントやモビリティ連携など）を明確に分けることが重要です。
【図表3】
出所：KPMG作成
最後に、最も重要なのは「期待値の設計」です。
SDR、SDN、SDSといった分野では、ユーザーが「ソフトウェアなら後から何でも変えられる」という成功体験を持っているため、SDVにも同じような柔軟性を期待しがちです。
しかしSDVでは、「何を変えられるか」と「変えるたびにどんな安全確認が必要か」が常にセットになります。つまり、すべてが自由に変えられるわけではなく、変更には責任と証明が伴うのです。
そのため、車を提供する側は、どこまでが画面やサービスの更新で即座に対応できるのか、どこからが安全性の検証を必要とするアップデートなのかを、ユーザーに対して明確に伝える必要があります。これを怠ると、過剰な期待とそれに続く失望を生むリスクがあります。
SDVは「ソフトウェアで定義される車」であると同時に、「安全によって定義される車」でもあるという理解が不可欠です。
自動車は公共の道路を走る製品であるからこそ、抽象化（機能の整理や共通化）の勝負は設計図のなかだけでなく、安全認証、運用体制、そしてユーザーへの価値提供の仕組みのなかで丁寧に作り込む必要があるのです。
執筆者
KPMGコンサルティング
プリンシパル 轟木 光
