数百万ドルから数十億ドル規模へ
グローバル自動車メーカー各社は、ソフトウェアの研究開発に年間 10 億ドル以上、販売車両 1 台あたりに換算して 1,000~3,000 ドルを投じています。では、各社は投じた金額に対して何を得ているのでしょうか？
消費者向け自動車の競争市場だけでなく、広範なサポートサプライチェーンにも重大なディスラプションが生じており、OEM 各社は現在、競争力を維持するためにソフトウェアの研究開発に多大なリソースを費やしています。OEM のソフトウェアの研究開発予算は、新たな機能や、車両システムおよび機能の制御に割り当てられています。
このような大規模な費用を投じる場合、OEM はソフトウェアの開発または購入の意思決定に先立って、顧客に高品質のサービスを提供するという OEM の最終的な目標に対して、それぞれのタイプのソフトウェアがどのような価値をもたらすのかを明確に理解しておく必要があります。
OEM

2021 年の車両1台あたりのソフトウェア選任スタッフの配置

ソフトウェア研究開発費

概算コスト（推定人員数）見積

1BMW10~15億ドル$3,0003,000-5,000人

Ford15億ドル~$1,5007,000人以上2$1,0002020年から2021年の間に17億5000万ドル
GM

15~17億5,000万ドル

新たに3,000人3
Mercedes-Benz

13~17億ドル$3,0004,000-7,000人

Toyota35~40億ドル$1,100トヨタと全子会社で18,000人4

Volkswagen

30~35 億ドル

$1,7502025 年までに10,000人以上5

表 1: OEM 各社によるソフトウェアの研究開発、人員配置、戦略的取り組みの例

このような「Vehicle OS」の取り組みは、チップ固有のファームウェアから、実際のデバイスオペレーティングシステム(Linux、Android、QNX など)、抽象化レイヤー、ミドルウェア、アプリケーション環境、さらには、車両のオンとオフ両方のアプリケーションレイヤーまで、ソフトウェアスタックのすべての領域をカバーします。ただし、ソフトウェアのレイヤーによって投資に対するリターンは大きく異なります。
特にミドルウェアへの投資は、OEM にとって難しい問題です。柔軟なソフトウェア戦略を展開し、ソフトウェアディファインドビークルに向けて取り組む上で、アプリケーションからハードウェアを抽象化するための適切な戦略を策定しておくことが重要です。一部の OEM では、ミドルウェアに比重をかけた戦略を策定することでしょう。しかしながら、ソフトウェアのコスト増により、抽象化レイヤー (特にミドルウェア) にとってはパートナーシップ締結や外から調達することが最善のアプローチであると考える OEM も、多く出てくる可能性があります。

- BMW 取締役 Frank Weber 氏

2高性能コンピュータは機能提供の機会であると同時に研究開発コストの課題
Volkswagen が ID ファミリーで採用する Continental ICAS のような「高性能コンピュータ」 (HPC) の登場は、OEM にとってチャンスと課題の両方を意味します。これらの高出力車両コンポーネントは、重要度や機能性の異なるシステムが同じハードウェア上で動作することを可能にするもので、デジタルコックピット、自動運転、および車両プラットフォームのコアコンピューティングシステムで広く使用されることが期待されています。この高性能コンピューテ
ィング環境が提案する基本的な価値とは、車両とクラウドの間でコンピューティングワークロードを動的にシフトし、「エッジで」 (この場合は車内で) より高度なコンピューティングが可能になるということです。このようなデバイスエッジコンピューティングを実現するソリューションアーキテクチャを開発することで、ネットワークやクラウドコンピューティングのコストを削減しながら、より応答性の高いサービスを実現することが可能となります。
ただし、エッジコンピューティングを行うソフトウェアプラットフォームの開発には多大な投資が必要です。SBD
Automotive では、車両データとアルゴリズム管理のための最も基本的かつ差別化されていないクラウドおよび車載ソフトウェアのビルディングブロックを開発し維持するためには、OEM は 10 年間で 6500 万ドルから 1 億1500 万ドルを投資する必要があると推定しています。さらにこれはソフトウェアへの投資全体のうちのほんの一部にすぎません。
ソフトウェアディファインドビークルの広範な技術スタック全体でこれらのコストを変換することで、ソフトウェアディファインドビークルの隠れた開発リスクが明らかになります。消費者の差別化に直接関与しないイネーブラーへの過剰投
資は、コスト増、開発リードタイムの長期化、長期的な持続可能性の低下、サイバーセキュリティ性能の低下につながります。自社でソフトウェアプラットフォームを所有および開発することへの過度な取り組みは、多くの場合、価値を生み出すことなく、車両のソフトウェア BOM に不必要なコストを投入してしまうことになります。

スケーラビリティの課題
野心的な大手自動車メーカーは、車両のソフトウェアスタックのほとんどを自社で所有および開発し、自社ブランドと OEM パートナーの両方でテクノロジー共有アライアンスを通じてこのプラットフォームを開発および共有することでスケーラビリティを実現する未来を明確に見据えています。

図1: トヨタの技術共有と資本提携

3例えば、Volkswagen の CEO、Herbert Deiss 氏は最近、車両のソフトウェアの約 60% を自社で「所有」(すなわち、開発、統合、展開) することへの野心を示しています。これは、ソフトウェアの大部分がサプライヤーによって作成されている今日の車両からの大転換となります。

図2、3

ソフトウェアディファインドビークルの領域において、他社をリードあるいは競争していくためには、こうした投資を行う
OEM は、車両のソフトウェアスタックのエンドツーエンドのアーキテクチャのための戦略的で目標に基づいたフレームワークを構築しておく必要があります。方向性を定めず資金と人材を投じることは問題の解決にはつながりません。明確なロードマップに沿ってリソースを活用し、差別化された製品とエクスペリエンスを構築することが必要です。

ほとんどの OEM にとって、ソフトウェアディファインドビークルのロードマップでコスト効率の高い取り組みを行うには、パートナー企業が提供するソリューション、オープンソースソフトウェア、またはこの 2 つの組み合わせが、ソフトウェアを有効にするために (価値を創造するのではなく) 特に必要となります。こうした比較的複雑なソフトウェアコンポー
ネントでは、特定の OEM のプラットフォームに対して最小限のカスタマイズしか必要としないため、スタック全体を社内で構築することは経済的に非効率的です。さらに、多くのサードパーティデベロッパーは、OEM 向けのソリューションのカスタマイズに必要な投資を最小限に抑えながら、対応可能な市場を最大化するために規模の経済を求めています。スケーラブルなベンダーソリューションと同じ機能を提供するカスタムの自社コンポーネントをゼロから開発すると、車両プラットフォーム開発ロードマップに 2~4 年という期間が追加され、さらには製品品質の低下につながる可能性があります。

ミドルウェアでソフトウェアをハードウェアから分離
従来、自動車メーカーとサプライヤーは、独自のハードウェアおよびデバイス OS 環境向けのソフトウェアを開発してきました。このアプローチは、複雑なレガシー技術の問題を生みだし、ソフトウェアディファインドビークル領域における進化(革新ではなく) を非常に困難なものにしていました。このタイプのソフトウェアはリソースの効率を向上させることができる一方で、ソフトウェアを特定のデプロイメントアーキテクチャに「結合」させるため、追加の車両プラットフォームやシステムへのアップデート、統合、拡張が困難になります。
ミドルウェアはソフトウェアを分離し、アップデート可能、スケーラブル、ポータブルなソフトウェア向けのプラットフォー
ムを構築する上で最も重要なツール
ミドルウェアという名前は、異なるコンポーネントまたは環境
図4の「中間」に立つというその機能に由来しています。この場合ミドルウェアは、ハードウェア固有のランタイムと特定のコンポーネント上のデバイスオペレーティングシステム、システム上で実行するために展開されるアプリケーションソフトウェアとの間に境界を形成します。

4

実際にはミドルウェアは、デバイス固有のランタイムを理解する負担を負う一方で、デプロイメント固有のニュアンスを、より高いレベルのソフトウェア用の標準化されたインターフェイスに変換します。これは、API (例: Toyota のArene プラットフォーム)、SDK (例: ブラックベリーの IVY ソリューション)、および/またはアプリケーションプラットフォーム全体 (例: Android ランタイム、AUTOSAR Adaptive Runtime for Applications、IVY など) の形をとることができます。これらのフルスタックランタイムは、車両のソフトウェアアーキテクチャにおける特定の問題を解決するよう設計されています。AUTOSAR Adaptive のランタイムは通常、ドメイン固有のソリューションを作成するために使用され、Android ランタイムは一般的に、アプリケーション (.apks) をホストし豊富なインフォテインメントUX を提供するために使用されます。IVY のランタイムは、車での分析ワークロードの安全な実行をサポートします。

コネクテッドミドルウェア:業界のリファレンス
ソフトウェアディファインドビークルプラットフォームの効果的な開およびサポートには、ミドルウェア戦略が必要です。ミ
ドルウェアは単一のコンポーネントではなく、包括的なサンドボックス化と抽象化を提供する一連のソフトウェアコンポーネントであるため (前述のすべてのランタイムの一部)、自動車メーカーは車両全体のシステムビューを捉え、各ドメイン (自動運転コックピットやデジタルコックピットなど) やそれぞれに関連するミドルウェアをキャプチャするソフトウェアアーキテクチャを導き出さなければなりません。
自動車固有のコネクテッドミドルウェアの例としては、Blackberry と Amazon Web Services (AWS) が、OEM をサポートしこれらの共通のニーズに対応するため、IVY を共同開発しました。このプラットフォームのアプリケーションは、下の図 5 で概要を示しています。この図では、AUTOSAR および Android のミドルウェアコンポーネントと連携する 1 つのミドルウェア製品 (IVY) を例として掲載しています。ここから、OEM がミドルウェア戦略に、オープンソース、標準化、あるいは購入というコンポーネントの選択肢を含めることができる、つまり、車両のソフトウェアインベントリを「所有」することが、すべてを内製することとイコールである必要はないということが言えます。

図 5: AUTOSAR Adaptive、Android Automotive と Blackberry IVY との統合
この場合、IVY の「合成センサー」 (データを処理したりアルゴリズムをトレーニングしたりする、本質的に小さな分析アプリケーション) は、車両の標準化された車載センサーインターフェースを使用して動作します。このアーキテクチャパターンでは、OEM、サードパーティデベロッパー、サプライヤー、その他認可された関係者が、ハードウェアのエンジニアリングや車両プラットフォーム固有の懸念事項を考慮することなくアプリケーションを構築できる、一様な抽象化レイヤーを提供します。
このような業界の一般的なミドルウェアソリューションを組み合わせることで、OEM はソフトウェアディファインドビークルの柔軟性を示すスケーラブルな統合を実現できます。
5

車両OS開発におけるコストとリスクのバランス – 開発と購入のモデリング
業界ではソフトウェアのインソーシング (OEM がサプライヤーにアウトソーシングするのではなく車両ソフトウェアを自社開発する) が進められていますが、これらコンポーネントの設計要件に対する多くの自動車メーカーの即時の反応が、それを自社で設計・開発する、ということなのかもしれません。結局のところ、これらのプラットフォーム上で実行される差別化ソフトウェアは、OEM の ソフトウェア開発の主なターゲットですが、そのプラットフォームを実現する基盤となる API およびサービスと同程度の能力しかありません。
ただし、実際の決定はそれほど単純ではなく、OEM がミドルウェアコンポーネントから何を必要とするかを長期的に把握する必要があります。ソフトウェアへの投資に対する最大のリターンは、顧客やビジネスに付加価値をもたらす新たなエクスペリエンス、機能、またはサービスを直接可能にするソフトウェアです。ミドルウェアは、インフラストラクチ
ャにおいて重要な役割を担うものの、直接それを可能にするわけではありません。
ソフトウェアおよびプラットフォームベンダーの HARMAN (Ignite)、Blackberry (IVY)、Continental(CAEdge)、Baidu (Apollo)や、業界コンソーシアムの AUTOSAR、GENIVI、Automotive Grade Linux(AGL) などでは、ミドルウェアによって重要な車両 OS およびミドルウェアインフラストラクチャを新規に開発する場合の数分の 1 のコストで提供できると同時に、OEM のソフトウェアディファインドビークルロードマップの市場投入までの時間を大幅に短縮できる可能性があると考えています。
SBD Automotive では自動車メーカーやサプライチェーンなどのパートナー企業へのヒアリングと弊社知見に基づき、ミドルウェアなどの車両 OS のコアイネーブラーを自社開発するか購入するかを決定する際に考慮すべき最も重要な要素について、下記の通りリストを作成しました。
購入する場合:ソフトウェアスペシャリストから車両OSインフラストラクチャを調達メリット:

デメリット:• 非経常費用 (NRE) と長期保守コストを大幅に削減• 契約および/またはマルチ OEM テストによりセキュリティが強化• ドメイン固有の特定分野の専門家にアクセス可能• 共通のマルチ OEM プラットフォーム上で動作するソフトウェアアプリケーションのスケーラビリティにより、サードパーティから新機能やサービスを追加するためのコストを削減• プロバイダのミドルウェアスタックの一部として設計されたツールやパートナーのエコシステムへの即時アクセス• 既存のデータサービス、トレーニングアルゴリズム、および (将来的な可能性として) 自動運転車およびコネクテッドカーのユースケースにおける様々な困難な問題の早期解消につなげるデータセットへのアクセスが可能• 車両スタックの専有ソフトウェアにより長期的なサプライヤーリスク• が生まれる• 新たな機能が必要な場合、製品ロードマップを直接管理することができない• OEMの製品リリース時またはリリース直後に低コストまたはオープンソースの代替手段が出現しより良い選択肢が利用可能となっても既に選択しているオプションに固執してしまう可能性がある。それにより従来のソフトウェアに問題が生じる可能性がある• OEMが過度の支出なし (例: 利用ベースで支払う) でミドルウェアスタックを最大限に活用することを妨げるような不利な契約となる可能性

開発する場合: ソリューションの設計、開発、統合、および保守を自社で行うメリット:

デメリット:• どのデータをどのように公開するかを直接管理可能• 実施されているセキュリティ管理策とその管理方法を直接コントロール
可能• サポートするツールチェーン (SDK、プラグイン、ライブラリ、Wikiなど) の幅や深度を直接管理可能• すべてのソフトウェアを OEM が所有するため、サプライヤーリスクがない• OEM が望むブランドアイデンティティと製品専用にキュレートされたパートナーエコシステム• 多額の非経常費用 （NRE） が事前に必要• 市場投入までの期間の長期化 (2年以上)• ミドルウェアスタックのさらなる開発、保守、リエンジニアリングに伴う多額の年間費用が発生• ソリューションを最新に保つための取り組みに多額のリエンジニアリン
グ費用が発生する可能性• テスト/ロバスト性の不足によるサイバーセキュリティリスク増大の可能性• ゼロからのエコシステム構築は成功の保証がないにもかかわらず、膨大な時間とリソースを消費表2 および表 3

ミドルウェアスタックを構築し統合するための戦略は、各自動車メーカーの企業戦略とビジネスの長期的なニーズに基づいて導き出す必要があります。SBD は、ソリューションをゼロから構築するために必要な投資の一部を定量化するために、車両エッジ処理、データ管理、アプリケーション/エッジソフトウェアライフサイクルに特化して設計されたミドルウェアスタックの総所有コストを算出するためのモデルを開発しました。
6

Internal development and operation of:Edge-to-cloud middleware
Vehicle data & analytics middleware

費用の内訳

図 6 および 77

ソフトウェアプロジェクトへの 1 億 1,500 万ドルという投資額は膨大な金額ではあるものの、これはソフトウェアディファインドビークルに必要なソフトウェア関連の投資全体で見ると、特にミドルウェアソフトウェアが収益化につながる直接的な機能やサービスを提供するわけではないことを考えると、ごく一部にすぎません。OEM ではこうした費用をより幅広いデータエコシステムを可能にするものとして正当化する可能性があり、また、規模の大きな量産車 OEMにそうした傾向がより見られると考えられます。ただし、こうした OEM にとっては業界パートナーとの協業というメリットもあります。しかしながら、生産や収益規模、ブランド価値に関わらずあらゆる OEM が、こうした新たな開発費用を削減すると同時に、より長い期間で同様の機能を内製している競合他社の一歩先を行くために、パートナー主導のアプローチを検討する必要があります。
提供開始後 OEM は、生産フリートを通じて重要なユースケースのロックを解除していくことになります。

ユースケース:グローバルフリート向けの新たな分析アルゴリズムをリアルタイムで展開

価値提案:

車両内 (対クラウド内) でデータ分析を実行することにより、エンジニアリングの労力をほとんどまたはまったく必要とせずに、新たなデータ駆動型のビジネスニーズまたは商業的機会をサポートする能力

例:

新たなデータ収集および分析アルゴリズムをすべての車両に展開することで、より広範なリアルタイムデータセット (例: バッテリーパフォーマンス、環境条件、ドライバー/車両の動作など) に基づいてフリートのパフォーマンスを監視するための圧縮バッテリー分析が可能となる

ユースケース:

デジタルコックピット、パワートレイン、自動運転、ボディ/シャーシなど、さまざまな車両コンポーネントとドメインをサポートする機械学習モデルのトレーニング

価値提案:

製品の品質とパフォーマンスを継続的に向上させ、より低コストで競争力の高い製品を生み出すと同時に、製品の強化により顧客ロイヤルティを高める例:

独自のドライバープロファイルの特性に基づいて、バッテリー性能を最適化するために機械学習モデルのトレーニングを行う

ユースケース:

OEM管理およびサードパーティ管理 (データマーケットプレイスやサービスプロバイダーパートナーなど) を含む複数のオフボードシステムへ車両データを安全かつセキュアに配布

価値提案:

どのデータをどこに送信するかについての車両固有の定義（クラウドではなく車両ランタイム自体に適用）により、データ送信コスト、クラウドコンピューティングコスト、およびクラウドベースのセキュリティリスクを低減させる

例:

特定の保険会社に関連する4〜5つの主要なデータポイントを導出するアルゴリズムを構成し、それらをドライバーの選択した保険会社に送信

ユースケース:ターゲットミドルウェア/エッジプラットフォームを実装するあらゆる車両で実行されるアルゴ
リズムまたは小さな「アプリケーション」をサードパーティが開発できるエコシステムを提供

自動車メーカーの価値提案:

付加価値アルゴリズム、パートナーサービス、機械学習モデルの事前開発されたライブラリへのアクセスにより、同様の自社サービスやオーダーメイドのパートナー統合を開発するコストを削減

開発者の価値提案:

プラットフォーム固有でない統合により、はるかに低い費用でスケールとボリュームにアクセスできるた
め、コンテンツやサービスのアドレス可能な市場が大幅に拡大

例:

気象情報会社は、データ収集および分析アルゴリズムを開発。これによりモデルデータと車両固有のセンサーデータを集約して、ドライバーに高度にローカライズされた予測と運転条件を提供

表 3、4、5、および68

目標達成のためのミドルウェア設計の重要性
問題は、OEM がソフトウェアディファインドビークルを構築するためにミドルウェアを必要とするかどうかではなく、OEMが必要なイネーブラーを最も効率的に提供するために、ミドルウェアをどのように統合および拡張できるかです。拡張
可能かつ有効なミドルウェアを備えたソフトウェアディファインドビークルプラットフォームの導入に成功した自動車メーカーが、重要な付加価値を生み出すことができます。
データのエッジ処理により、特にADASドメインでの車載機能の抽象化されたハードウェアとセンサーによって実現されるテストおよび向上、およびOTAデータコストの大幅な最適化が実現

シミュレーション機能の強化により、製品開発サイクルが短縮

ハードウェアではなくミドルウェアで実行するよう構築された、ハーリアルタイムかつ予測的サービスを提供する統合されたエッジアプリ

ドウェアに依存しないアプリケーションからの低コストで多様なハーケーションによる、よりスマートでパーソナライズされた車内エクス

ドウェアおよび半導体サプライチェーン

ペリエンス
表7

業界の利害関係者は、5 年後、あるいは 10 年後の自社のビジネスを見据えた戦略的な意思決定を直ちに下す必要があります。これらの選択が、ソフトウェアロードマップにおける施策の実行や、ディスラプションへの対応に大きな影響を与えることになります。OEM が今後 10 年間に展開可能な機能や収益ストリームを定義するうえで、組織に適切なミドルウェアを統合する方法を理解しておくことが重要です。OEM が規模、能力、予算に適した選択をするためには、ソフトウェアを管理するためにすべてを自社で構築する必要がないということを理解しておく必要があります。

参照
1 SBD Automotive research, aggregating public financial reporting, news reports, and annual volumes
2 https://techstory.in/ford-offers-buyout-for-select-skill-teams-plans-to-attract-softwareemployees/
3 https://media.gm.com/media/us/en/gm/home.detail.html/content/Pages/news/us/en/2020/nov/1109-tech- jobs.html
4 https://global.toyota/en/newsroom/corporate/35891478.html
5 https://www.volkswagenag.com/en/news/fleet-customer/2021/01/transformers.html

SBD Automotive について
SBD Automotive は、自動車技術を専門とする調査・コンサルティング会社です。20 年以上にわたり、日本、欧州（英国とドイツ）、米国、中国の拠点から自動車業界に携わるクライアントをグローバルにサポートしています。クライアントは自動車メーカー、サプライヤー、保険業界、通信業界、政府・公的機関、研究機関など自動車業界のバリューチェーン全体にわたり、調査対象エリアは欧州、北米、中国、ブラジル、インド、ロシア、東南アジアなど世界各国の市場を網羅します。自動車セキュリティおよび IT、コネクテッドカー、自動運転、電気自動車などの分野において調査を実施し、各種レポートやコンサルティングサービスを提供しています。
お問合せ先:SBD Automotive ジャパン
〒460-0002 名古屋市中区丸の内 2-18-22 三博ビル 6F
Tel: 052 253 6201
E-mail: postbox@sbdautomotive.com
https://www.sbdautomotive.com/ja/

9