SDV（Software Defined Vehicle）とは何か。クルマだけではないSDVの世界を定義する

2. SDVとは何か

a. SDVはモビリティそのものではなくエコシステムであり、その中心はユーザーである

自動運転車のSAE^*2レベルや電動化（HEV、PHEV、BEV、FCEV）と異なり、SDVの定義は曖昧であり、主体となるプレーヤーそれぞれの視点で捉え方は異なります。SDVにはVehicleという言葉が入っていますが、モビリティ自体のみならず、モビリティの内と外（In-car／Out-car）および、そこらから導出されるユーザーへの価値提供という概念が含まれます。そのため、私たちはSDVを「ソフトウェアを基軸にモビリティの内と外を繋ぎ、機能を更新し続けることで、ユーザーに新たな価値および体験を提供し続けるための基盤（エコシステム）」と定義しています。

SDVの中心はモビリティではなく、ユーザーそのもの、あるいはユーザーに提供する価値や体験であると捉えることが重要で、モビリティやクラウド、その他関連する技術などはそのための手段として捉えることが肝要です（図表2）。

SDVに関係するプレーヤーは、車両OEM、Tier1サプライヤ、Tier2サプライヤ（含むソフトウェア関連ベンダー）、半導体メーカー、OTA（Over The Air）サーバー事業者、その他サービス事業者、官公庁など数多く存在します。これらプレーヤーそれぞれの視点でSDVの捉え方は大きく変わってくるため、基盤（エコシステム）全体をSDVであると定義し、俯瞰することで、SDV全体を正しく把握できると考えます。

b. SDVレベルを定義する

SDVはSAEが定めた自動運転車のレベルと同様に、レベル0からレベル5で表現することができると、PwCは考えます。SAE自動運転レベルと同様の考え方でレベル3以上をSDVと定義すると、現時点ではトップランナーがレベル4に達しており、多くの企業はレベル2からレベル3、あるいはレベル3からレベル4を目指しているのが現状です。レベル0ではメカ／ハードウェアが主体でしたが、レベルが上がるごとに、ユーザーはソフトウェアやモビリティの外により多くの知覚価値（あくまで定性的なイメージとして捉える）を感じられるようになります（図表3）。

• Level 0：Mechanical Controlled Vehicle（機械制御車両）

エンジン機能など一部で電気電子制御される一方、主として機械部品が協調することで走行機能を実現する車両です。

• Level 1：E/E Controlled Vehicle（電気電子制御車両）

独立したECU（Electric Control Unit）が複数存在し、車両機能のE/E（電気電子）化が進んだ状態です。主にディスクリート部品で電気電子的に制御され、比較的小規模なマイコンにソフトウェアが組み込まれたECUを搭載した車両です。

• Level 2：Software Controlled Vehicle（ソフトウェア制御車両）

走行以外にモビリティに求められる機能が増えることでECU数が増加し、ドメインごとに切られたCAN（Controller Area Network）通信などの数Mbps（bit per second）の車載ネットワークによりバス管理された車両です。マイコンの規模も比較的大きくなりSoC（System on a Chip）も一部で活用され、ソフトウェア規模も比較的大きな車両です。OTA機能はありますがインフォテイメントに限定され、リコールなどのソフトウェア不具合修正は有線通信による対応が中心となります。

• Level 3：Partial Software Defined Vehicle（部分ソフトウェア定義車両）

ドメインアーキテクチャ^*3によりECUの統合化が進み、統合した機能制御をHPC（High Performance Computing）用の大規模SoCが実現します。また、一部でビークルOSやAPI（Application Programming Interface）標準化が進みます。車載通信も100Mbpsから1Gbps程度の車載Ethernet通信により高速化され、ドメインコントローラを中心にセントラル化が進みます。不具合以外の機能追加および商品性向上のための積極的なソフトウェアアップデートがOTAにより実施され、モビリティ販売以外の収益モデルも一部で取り入れられます。なお、レベル3以上をSDVと定義します。

• Level 4：Full Software Defined Vehicle（完全ソフトウェア定義車両）

ゾーンアーキテクチャ^*4により機能の最適配置および拡張性が増加します。ビークルOSやAPI標準化によりハードウェアとソフトウェア分離（ディカップリング）が進み、クラウドベースの仮想開発環境やソフトウェアファースト開発などによるシフトレフトが加速します。また、ディカップリング効果を最大化するために、ハードウェアリッチに設計し、予約設計を実現します。車載通信も数Gbps以上とさらに高速化されることで、自動運転向けなどの大規模／高速データ通信も容易となります。機能追加／商品性向上のための積極的かつ高頻度なOTAソフトウェアアップデートが実施されることで、購入後もモビリティの価値が継続します。車両販売以外の収益モデルも多く構築されます。

• Level 5：Software Defined Ecosystem（ソフトウェア定義エコシステム）

モビリティとモビリティ外がシームレスに常時接続され、AIなどの頭脳系制御がモビリティ外に移ることにより、モビリティ内のソフトウェアアップデートのみならず、モビリティ外における常時学習により、市場データおよびユーザーニーズなどを常に満たした状態とすることが可能です。インフォテイメント系ではモビリティによらず共通したアプリおよびサービスが提供可能となり、モビリティの価値がソフトウェアおよびサービス側に大きく移行します。APIの標準化がさらに進み、スマートフォンのアプリのように、一般ユーザーによる車両アプリの開発や販売が実現します。ハードウェアのプラグアンドプレイの容易性が高まることで、ハードウェアアップデートによる価値継続も可能となります。開発領域を含め、これまで以上にユーザーとモビリティとのタッチポイントが増加します。これらにより、モビリティ価値がエコシステム全体を通じて底上げされ、ユーザー価値および体験を最大化およびアップデートし続けることが可能となります。

PwCではSDVレベルを10の要素（UX、収益構造、アプリ／サービス販売、ITインフラ／データ、コネクティビティ、E/Eアーキテクチャ、ソフトウェア開発、ソフトウェア構造、サイバーセキュリティ、半導体）に分解し、各要素のレベルごとに状態を定義しています。つまり、SDVレベルはある要素においてはレベル3だったとしても、異なる要素ではレベル4となる場合も考えられるため、対応するプレーヤーごとに各要素の現状を正しく把握し、目指す状態を要素ごとに設定することで、「目指すSDV像」を業界横断で明確にすることができます。またこのSDVレベルの10要素は業界の広がりや要素技術の追加に伴い、今後柔軟に拡張することを前提としています（図表4）。

4. 伝統OEMと新興OEMで攻め方は大きく異なる

ICE開発から長い期間をかけて技術革新を進めてきた伝統OEMの多くは、これまで積み上げた技術力／対応力、設計資産、大規模な開発リソース、グローバルサプライチェーン、グローバル販売網などを武器にSDV化、自動運転、電動化を推し進めています。一方で、ICEからBEV/FCEVまで全ラインナップに対応し、SDVもレベル2（ソフトウエア制御車両）の分散したECUごとに開発チームが分かれている状態であり、その体制を維持しながら、SDVレベル3（部分ソフトウェア定義車両）のドメインコントローラやレベル4（完全ソフトウェア定義車両）向けのゾーン／セントラルコントローラを段階を経ながら開発する必要があります。足元の収益をSDVレベル2やICE/HEV向けの組織から生み出しつつ、将来のSDVレベル3～4に向けた開発投資およびリソース最適配分を行う必要があるため、大きな挑戦やスピード感を持った投資判断は難しいと言えます。

他方で、ここ10数年の間に設立された新興OEMは、過去からの積み上げやリソースは大きくないですが、しがらみがない分、最初からBEVに振り切り、ドメインやゾーンアーキテクチャなどの最適なE/Eアーキテクチャを集中開発するなどして、限られたリソースの中でスピード感をもって成長してきました。組織の壁がない状態からスタートできるため、既存のしがらみにとらわれず最適な組織を作ることができる特長はありますが、「走る車」を作ることはできたとしても、モビリティとして長期にわたり高い品質で安心・安全を提供し、多くの法規や各種規制を満たすことは並大抵ではありません。グローバルにスケールし、多くの経験・知見を蓄積する伝統OEMには一朝一夕では追いつけない部分もあると考えます。新興OEMが大きくスケールするためには、伝統OEMやサプライヤの良い部分を学び、外から適切な人材を獲得するなどの対応が求められます（図表6）。

伝統OEMと新興OEMでは置かれた状況が大きく異なるため、それぞれに適した方法でSDV化、自動運転化、電動化を推し進める必要があります。また、OEMと違い、サプライヤは伝統系および新興系の両方の戦略／状況を常に正しく把握し、両方に対応するか、どちらかに寄り添うかを考えなくてはなりません。特に製品ラインナップが多いメガサプライヤにとっては、基本的には両軸への対応が求められると考えられるため、伝統に寄り添いつつ、スピード感を持った開発／変化への対応が肝要となります。

*1 CASE（Connected、Autonomous、Shared & Service, Electricの頭文字）
*2 Society of Automotive Engineersの略語
*3 パワートレインやインフォテイメント、ADAS／自動運転などの機能要素（ドメイン）を軸にE/Eアーキテクチャを構築するもの
*4 機能要素（ドメイン）軸に依らずセンサーやアクチュエータの物理配置（ゾーン）に合わせて、最適に機能を配置するE/Eアーキテクチャ