マッキンゼー: 自動車分野のソフトウェアとエレクトロニクス アーキテクチャを再考する

自動車がハードウェア主導からソフトウェア主導への移行を続ける中、自動車業界の競争ルールは劇的に変化しています。

エンジンは 20 世紀の自動車の技術的およびエンジニアリングの中核でした。 今日、この役割はソフトウェア、より優れたコンピューティング能力、高度なセンサーによってますます果たされています。 ほとんどのイノベーションにはこれらすべてが含まれます。 自動車の効率性、インターネットへのアクセス、自動運転の可能性から、電動モビリティや新しいモビリティ ソリューションに至るまで、すべてはこれらに依存します。

ただし、エレクトロニクスとソフトウェアの重要性が高まるにつれて、その複雑さのレベルも高まります。 最新の自動車に含まれるコード行数 (SLOC) の増加を例に挙げます。 2010 年には、一部の車両には約 2016 万個の SLOC が搭載されていました。 15 年までに、この数字は 150 倍の約 XNUMX 億 XNUMX 万行のコードに増加しました。 新車の数多くのレビューで明らかなように、雪崩のような複雑さはソフトウェアの品質に深刻な問題を引き起こします。

自動車の自律性レベルが向上しました。 したがって、自動車業界で働く人々は、ソフトウェアと電子機器の品質と安全性が人の安全を確保するための重要な要件であると考えています。 自動車業界は、ソフトウェアと電気電子アーキテクチャに対する最新のアプローチを再考する必要があります。

業界の差し迫った問題を解決する

自動車業界がハードウェア主導のデバイスからソフトウェア主導のデバイスに移行するにつれて、車両に搭載されるソフトウェアと電子機器の平均量が急速に増加しています。 現在、ソフトウェアは、D セグメント以上の車の総コンテンツの 10% (約 1220 ドル) を占めています。 ソフトウェアの平均シェアは 11% 増加すると予想されています。 2030 年までにソフトウェアが車両の総コンテンツ (約 30 ドル) の 5200% を占めるようになると予測されています。 自動車開発のある段階に携わる人々が、ソフトウェアやエレクトロニクスによって可能になるイノベーションから恩恵を受けようとしているのは驚くべきことではありません。

ソフトウェア会社やその他のデジタルプレーヤーは、もはや取り残されることを望んでいません。 彼らは自動車メーカーを一次サプライヤーとして引き付けようとしている。 企業は、機能やアプリケーションからオペレーティング システムに移行することで、自動車テクノロジー スタックへの参加を拡大しています。 同時に、電子システムの取り扱いに慣れている企業は、大手テクノロジー企業のテクノロジーやアプリケーションの領域に果敢に参入しています。 高級車メーカーは独自のオペレーティング システム、ハードウェア抽象化、および信号処理の開発を進め、自社の製品を本質的にユニークなものにしています。

上記の戦略には結果が伴います。 将来的には、共通のコンピューティング プラットフォームに基づく車両サービス指向アーキテクチャ (SOA) が登場するでしょう。 開発者は、インターネット アクセスの分野のソリューション、アプリケーション、 人工知能の要素、高度な分析とオペレーティング システム。 違いは自動車の従来のハードウェアではなく、ユーザー インターフェイスと、ソフトウェアと高度な電子機器との連携方法にあります。

未来の自動車は、新しいブランドの競争力のあるプラットフォームに移行します。

これらにはインフォテインメントのイノベーションが含まれる可能性が高く、 自動運転機能 「フェールセーフ」動作に基づくインテリジェントな安全機能（例：システムの一部が故障した場合でも主要な機能を実行できるシステム）。 ソフトウェアはデジタル スタックを下り続け、スマート センサーを装ってハードウェアの一部となるでしょう。 スタックは水平統合され、アーキテクチャを SOA に移行する新しいレイヤーを受け取ります。

ファッションのトレンドはゲームのルールを変えます。 それらはソフトウェアと電子アーキテクチャに影響を与えます。 こうした傾向により、テクノロジーの複雑さと相互依存が促進されます。 たとえば、新しいスマート センサーとアプリケーションは、 車内の「データブーム」。 自動車会社が競争力を維持したい場合は、データを効果的に処理して分析する必要があります。 モジュラー SOA アップデートと無線 (OTA) アップデートは、フリート内の複雑なソフトウェアをサポートするための重要な要件になります。 また、オンデマンドで機能が表示される新しいビジネス モデルの実装にとっても非常に重要です。 インフォテインメント システムの使用は増加し、程度は低いものの、高度なシステムが使用されるようになります。 運転支援システム (ADAS)。 その理由は、車両用の製品を提供するサードパーティのアプリ開発者が増えているためです。

デジタル セキュリティ要件により、従来のアクセス制御戦略は興味深いものではなくなりました。 に切り替える時が来ました 統合された安全コンセプト、サイバー攻撃を予測、防止、検出、保護するように設計されています。 高度自動運転 (HAD) 機能が出現すると、機能の統合、優れたコンピューティング能力、高レベルの統合が必要になります。

将来の電気または電子アーキテクチャに関する XNUMX の仮説を探る

テクノロジーとビジネスモデルの両方の開発の道筋はまだ明確に定義されていません。 しかし、私たちは広範な調査と専門家の意見に基づいて、将来の電気自動車または電子自動車のアーキテクチャとその業界への影響に関する XNUMX の仮説を立てました。

電子制御ユニット（ECU）の統合はますます一般的になる

現在の「機能を追加し、ウィンドウを追加する」スタイルのように、特定の機能に複数の特定の ECU を使用するのではなく、業界は統合された車両 ECU アーキテクチャに移行することになります。

最初のフェーズでは、ほとんどの機能がフェデレーション ドメイン コントローラーに焦点を当てます。 コア車両ドメインでは、現在分散型 ECU で利用可能な機能が部分的に置き換えられます。 開発はすでに始まっています。 完成品はXNUMX～XNUMX年以内に市場に投入される予定です。 統合は、ADAS および HAD 機能に関連するスタックで発生する可能性が最も高くなりますが、より基本的な車両機能は高度な分散化を維持する可能性があります。

自動運転に向けて進んでいます。 したがって、ソフトウェア機能の仮想化とハードウェアからの抽象化が不可欠になります。 この新しいアプローチはさまざまな方法で実装できます。 ハードウェアを組み合わせて、さまざまな遅延と信頼性の要件を満たすスタックを作成することが可能です。 例としては、HAD および ADAS 機能をサポートする高性能スタックと、コア セキュリティ機能用の別個の低遅延時間駆動スタックが挙げられます。 あるいは、ECU を XNUMX 台のバックアップ「スーパーコンピューター」に置き換えることもできます。 もう XNUMX つの考えられるシナリオは、コントロール ユニットの概念を完全に放棄し、スマート コンピューティング ネットワークを選択する場合です。

この変化は主に、コスト、新規市場参入者、HAD の需要という XNUMX つの要因によって引き起こされます。 機能開発のコストと、通信機器を含む必要なコンピューティング ハードウェアを削減することで、統合プロセスがスピードアップします。 同じことは、車両アーキテクチャに対するソフトウェア中心のアプローチで業界を破壊する可能性が高い自動車市場への新規参入者にも言えます。 HAD 機能と冗長性に対する需要の高まりにより、より高度な ECU 統合も必要になります。

一部の高級自動車メーカーとそのサプライヤーは、すでに ECU の統合に積極的に取り組んでいます。 彼らは電子アーキテクチャを更新するための最初の一歩を踏み出していますが、現時点ではまだプロトタイプはありません。

業界は特定の機器に使用されるスタックの数を制限する予定です

統合サポートにより、スタック制限が正規化されます。 車両とECUハードウェアの機能を分離し、仮想化を積極的に活用する。 ハードウェアとファームウェア (オペレーティング システムを含む) は、車両の機能領域の一部ではなく、中核となる機能要件に依存します。 分離とサービス指向アーキテクチャを確保するには、スタックの数を制限する必要があります。 以下は、5 ～ 10 年後に将来の世代の自動車の基礎を形成する可能性のあるスタックです。

• 時間主導のスタック。 このドメインでは、コントローラーはセンサーまたはアクチュエーターに直接接続されますが、システムは低遅延を維持しながら厳しいリアルタイム要件をサポートする必要があります。 リソースのスケジューリングは時間ベースです。 このスタックには、最高レベルの車両安全性を実現するシステムが含まれています。 例としては、古典的な Automotive Open Systems Architecture (AUTOSAR) ドメインがあります。
• 時間およびイベント駆動型スタック。 このハイブリッド スタックは、高性能セキュリティ アプリケーションと、たとえば ADAS や HAD のサポートを組み合わせます。 アプリケーションと周辺機器はオペレーティング システムによって分離されますが、アプリケーションはタイムスケジュールされます。 アプリケーション内では、時間または優先度に基づいてリソースのスケジュールを設定できます。 動作環境により、ミッションクリティカルなアプリケーションが隔離されたコンテナ内で実行され、これらのアプリケーションが車内の他のアプリケーションから明確に分離されます。 良い例は適応型 AUTOSAR です。
• イベント駆動型スタック。 このスタックは、安全性が重要ではないインフォテインメント システムに焦点を当てています。 アプリケーションは周辺機器から明確に切り離されており、リソースは最適なスケジューリングまたはイベントベースのスケジューリングを使用してスケジュールされます。 スタックには、Android、Automotive Grade Linux、GENIVI、QNX など、頻繁に使用される目に見える機能が含まれています。 これらの機能により、ユーザーは車両と対話できるようになります。
• クラウドスタック。 最後のスタックはデータ アクセスをカバーし、データと車両の機能を外部から調整します。 このスタックは通信とアプリケーションのセキュリティ検証 (認証) を担当し、リモート診断を含む特定の自動車インターフェイスを確立します。

自動車サプライヤーやテクノロジーメーカーは、すでにこれらのスタックの一部に特化し始めています。 代表的な例はインフォテインメント システム (イベント駆動型スタック) で、企業はそこで通信機能 (3D および高度なナビゲーション) を開発しています。 XNUMX 番目の例は、高性能アプリケーション向けの人工知能とセンシングで、サプライヤーが主要な自動車メーカーと協力してコンピューティング プラットフォームを開発しています。

時間駆動の領域では、AUTOSAR と JASPAR がこれらのスタックの標準化をサポートします。

ミドルウェアはハードウェアからアプリケーションを抽象化します

車両がモバイル コンピューティング プラットフォームに向けて進化し続けるにつれて、ミドルウェアによって車両の再構成やソフトウェアのインストールと更新が可能になります。 現在では、各 ECU のミドルウェアにより、デバイス間の通信が容易になります。 次世代の車両では、ドメイン コントローラーとアクセス機能がリンクされます。 自動車の ECU ハードウェアを使用して、ミドルウェアは抽象化、仮想化、SOA、分散コンピューティングを提供します。

自動車業界がミドルウェアを含む、より柔軟なアーキテクチャに移行しているという証拠はすでにあります。 たとえば、AUTOSAR 適応プラットフォームは、ミドルウェア、複雑なオペレーティング システムのサポート、最新のマルチコア マイクロプロセッサを含む動的なシステムです。 ただし、現時点で利用可能な開発は XNUMX つの ECU のみに限定されています。

中期的には、搭載センサーの数が大幅に増加する

次の XNUMX ～ XNUMX 世代の車両では、自動車メーカーは、安全関連の予備が十分であることを確認するために、同様の機能を備えたセンサーを搭載することになります。

長期的には、自動車業界は専用のセンサー ソリューションを開発して、センサーの数とコストを削減するでしょう。 私たちは、レーダーとカメラを組み合わせることが、今後 4 ～ 360 年で最も一般的なソリューションになる可能性があると考えています。 自動運転機能が成長し続けるにつれて、ライダーの導入が必要になります。 これらは、オブジェクト分析の分野とローカリゼーションの分野の両方に冗長性を提供します。 たとえば、SAE International LXNUMX (高度自動化) 自動運転構成では、当初は都市ナビゲーションとほぼ XNUMX 度の視認性のために後部に取り付けられたものを含め、XNUMX ～ XNUMX 個の LIDAR センサーが必要となる可能性があります。

長期的に車両に搭載されるセンサーの数について何かを言うのは困難です。 その数は増加するか、減少するか、または変化しません。 それはすべて、規制、ソリューションの技術的成熟度、さまざまなケースで複数のセンサーを使用できるかどうかによって異なります。 たとえば、規制要件によりドライバーの監視が強化され、車内のセンサーが増加する可能性があります。 車内に家電製品のセンサーが使用されることがさらに増えることが予想されます。 モーション センサー、健康モニタリング (心拍数と眠気)、顔認識と虹彩認識は、考えられる使用例のほんの一部です。 ただし、センサーの数を増やしたり、現状を維持したりするには、センサー自体だけでなく車両ネットワークにも、より広範囲の材料が必要になります。 したがって、センサーの数を減らす方がはるかに有益です。 高度に自動化された車両または完全自動化された車両の出現により、高度なアルゴリズムと機械学習によりセンサーの性能と信頼性が向上します。 より強力で有能なセンサー技術のおかげで、不必要なセンサーは不要になる可能性があります。 現在使用されているセンサーは時代遅れになる可能性があります。より高機能なセンサーが登場するでしょう (たとえば、カメラベースの駐車アシスタントや LIDAR の代わりに、超音波センサーが登場する可能性があります)。

センサーはさらに賢くなる

システム アーキテクチャには、高度な自動運転に必要な膨大な量のデータを管理するためのインテリジェントな統合センサーが必要です。 センサー フュージョンや XNUMXD ポジショニングなどの高レベルの機能は、集中型コンピューティング プラットフォーム上で実行されます。 前処理、フィルタリング、および高速応答ループは、エッジに配置されるか、センサー自体の内部で実行される可能性があります。 ある推定では、自動運転車が XNUMX 時間ごとに生成するデータの量は XNUMX テラバイトです。 したがって、AI は ECU からセンサーに移動して、基本的な前処理を実行します。 特にセンサー内のデータ処理のコストと車両内で大量のデータを送信するコストを比較した場合、低レイテンシーと低い計算パフォーマンスが必要です。 ただし、HAD における道路決定の冗長性には、集中型コンピューティングのためのコンバージェンスが必要です。 おそらく、これらの計算は前処理されたデータに基づいて計算されます。 スマート センサーは独自の機能を監視し、センサーの冗長性によりセンサー ネットワークの信頼性、可用性、ひいてはセキュリティが向上します。 あらゆる条件下でセンサーの適切な性能を確保するには、凍結防止剤や塵埃除去剤などのセンサー洗浄アプリケーションが必要になります。

フルパワーの冗長データ ネットワークが必要になります

高い信頼性を必要とする重要なアプリケーションや安全性が重要なアプリケーションでは、安全な操縦に必要なすべてのもの (データ通信、電力) に完全な冗長サイクルが使用されます。 電気自動車技術の紹介、中央コンピュータおよび電力を大量に消費する分散コンピューティング ネットワークには、新しい冗長電源管理ネットワークが必要です。 有線制御やその他の HAD 機能をサポートするフォールト トレラント システムには、冗長システムの開発が必要です。 これにより、最新のフォールト トレラント監視実装のアーキテクチャが大幅に改善されます。

クルマの根幹となる「車載Ethernet」

今日の自動車ネットワークは、将来の輸送ニーズを満たすには十分ではありません。 データ レートの増加、HAD の冗長性要件、接続された環境におけるセキュリティと保護の必要性、業界を超えた標準化されたプロトコルの必要性により、車載イーサネットの出現につながる可能性があります。 これは、特に冗長中央データ バスにとって重要なイネーブラーとなります。 イーサネット ソリューションには、ドメイン間で信頼性の高い通信を提供し、リアルタイムの需要を満たすことが求められます。 これは、オーディオ ビデオ ブリッジング (AVB) や時間依存ネットワーク (TSN) などのイーサネット拡張機能の追加により可能になります。 業界代表者と OPEN Alliance は、イーサネット テクノロジーの採用をサポートしています。 多くの自動車メーカーはすでにこの大きな一歩を踏み出しています。

ローカル相互接続ネットワークやコントローラー ネットワークなどの従来のネットワークは引き続き車両内で使用されますが、センサーなどの閉じた下位レベルのネットワークにのみ使用されます。 FlexRay や MOST などのテクノロジーは、車載イーサネットとその拡張機能である AVB および TSN に置き換えられる可能性があります。

将来的には、自動車業界でも HDBP (高遅延帯域幅製品) や 10 ギガビット テクノロジーなどの他のイーサネット テクノロジーが使用されると予想されます。

OEM は機能安全と HAD を確保するためにデータ接続を常に厳密に制御しますが、サードパーティがデータにアクセスできるようにインターフェイスをオープンします。

セキュリティ上重要なデータを送受信する中央通信ゲートウェイは、常に OEM バックエンドに直接接続します。 規則で禁止されていない場合、データへのアクセスは第三者に公開されます。 インフォテイメントは車両の「付属品」です。 この分野では、新たに登場したオープン インターフェイスにより、コンテンツ プロバイダーやアプリケーションが製品を導入できるようになり、OEM はできる限り標準を遵守できるようになります。

現在のオンボード診断ポートは、接続されたテレマティクス ソリューションに置き換えられます。 車両ネットワークへのメンテナンス アクセスは必要なくなりますが、OEM バックエンドを介してアクセスできるようになります。 OEM は、特定の使用例 (盗難車両の追跡や個人保険) のために車両後部にデータ ポートを提供します。 ただし、アフターマーケット デバイスは、内部データ ネットワークにアクセスできなくなります。

大規模なフリートオペレーターは、ユーザーエクスペリエンスにおいてより大きな役割を果たし、最終顧客に価値を生み出すでしょう。 同じサブスクリプション内で、さまざまな目的（毎日の通勤や週末の旅行など）に応じてさまざまな車両を提供できるようになります。 複数の OEM バックエンドを使用し、フリート全体でデータを統合する必要があります。 大規模なデータベースにより、フリート事業者は、OEM レベルでは利用できない統合データと分析を収益化できるようになります。

自動車はクラウド サービスを使用して車載情報と外部データを組み合わせる

「非機密」データ (つまり、ID やセキュリティに関連しないデータ) は、追加情報を取得するためにクラウドで処理されることが増えています。 OEM 以外でこのデータを利用できるかどうかは、将来の法律や規制によって異なります。 量が増えるにつれて データ分析なしでは不可能です。 情報を処理し、重要なデータを抽出するには、分析が必要です。 当社は自動運転やその他のデジタルイノベーションに取り組んでいます。 データを効果的に活用できるかどうかは、複数の市場参加者間でデータを共有できるかどうかにかかっています。 誰がどのようにこれを行うのかはまだ不明です。 しかし、主要な自動車サプライヤーやテクノロジー企業は、この新たな豊富なデータを処理できる統合自動車プラットフォームをすでに構築しています。

双方向通信をサポートするアップグレード可能なコンポーネントが車両に登場します

車載テストシステムにより、車両がアップデートを自動的にチェックできるようになります。 車両のライフサイクルとその機能を管理できるようになります。 すべての ECU はセンサーやアクチュエーターとデータを送受信し、データを取得します。 このデータはイノベーションの開発に使用されます。 例としては、車両パラメータに基づいてルートを構築することが挙げられます。

OTA アップデート機能は HAD にとって必須です。 これらのテクノロジーにより、新しい機能、サイバーセキュリティが実現し、機能やソフトウェアの展開が迅速化されます。 実際、OTA アップデート機能は、上で説明した多くの重要な変更の背後にある原動力です。 さらに、この機能には、車両の外側と ECU 内の両方のスタックのすべてのレベルで包括的なセキュリティ ソリューションも必要です。 このソリューションはまだ開発されていません。 誰がどのようにそれを行うのかを見るのは興味深いでしょう。

車のアップデートはスマートフォンのようにインストールできるのでしょうか? 業界は、サプライヤー契約の制限、規制要件、セキュリティとプライバシーの問題を克服する必要があります。 多くの自動車メーカーは、車両の無線アップデートを含む OTA サービスを展開する計画を発表しています。

OEM は、この分野のテクノロジー プロバイダーと緊密に連携して、OTA プラットフォームで自社のフリートを標準化します。 車載接続と OTA プラットフォームは間もなく非常に重要になるでしょう。 OEM はこれを理解しており、この市場セグメントでさらに多くの所有権を獲得しようとしています。

車両には、設計期間中、ソフトウェア、機能、セキュリティのアップデートが提供されます。 規制当局は車両の設計の完全性を確保するためにソフトウェアのメンテナンスを提供する可能性が高い。 ソフトウェアの更新と保守の必要性は、車両の保守と運用の新しいビジネス モデルにつながります。

自動車ソフトウェアと電子アーキテクチャの将来の影響の評価

自動車業界に影響を与えるトレンドにより、ハードウェア関連の重大な不確実性が生じています。 しかし、ソフトウェアと電子アーキテクチャの将来は有望に見えます。 業界にはあらゆる可能性が開かれています。自動車メーカーは車両アーキテクチャを標準化するために業界団体を設立することができ、デジタル巨人は車載クラウドプラットフォームを実装することができ、モビリティ企業は独自の車両を製造したり、オープンソースコードと機能ソフトウェアを使用して車両スタックを開発したり、自動車メーカーは次のような可能性があります。インターネット接続を備えた自動運転車はますます洗練されています。

製品はまもなくハードウェア中心ではなくなります。 それらはソフトウェア指向になります。 従来の自動車の生産に慣れている自動車会社にとって、この移行は困難となるだろう。 しかし、ここで述べた傾向と変化を考慮すると、中小企業であっても選択の余地はありません。 彼らは準備をしなければならないだろう。

いくつかの主要な戦略的ステップがわかります。

• 車両の開発サイクルと車両の機能を分離します。 OEM と Tier XNUMX サプライヤーは、機能をどのように開発、提供、展開するかを決定する必要があります。 技術的および組織的な観点の両方から、車両開発サイクルから独立していなければなりません。 現在の車両開発サイクルを考慮すると、企業はソフトウェアのイノベーションを管理する方法を見つける必要があります。 さらに、既存のフリートのアップグレードおよびアップグレード (コンピューティング ユニットなど) のオプションを考慮する必要があります。
• ソフトウェアおよびエレクトロニクス開発の目標付加価値を定義します。 OEM は、ベンチマークを設定できる差別化機能を特定する必要があります。 さらに、自社のソフトウェアおよびエレクトロニクス開発の目標付加価値を明確に定義することが重要です。 また、製品が必要となる領域や、サプライヤーまたはパートナーとのみ話し合うべきトピックも特定する必要があります。
• ソフトウェアの明示的な価格を設定します。 ソフトウェアをハードウェアから切り離すために、OEM はソフトウェアを直接購入するための内部プロセスとメカニズムを再考する必要があります。 従来のカスタマイズに加えて、ソフトウェア開発へのアジャイルなアプローチを調達プロセスにどのように結びつけることができるかを分析することも重要です。 ここでは、ベンダー (ティア XNUMX、ティア XNUMX、ティア XNUMX) も重要な役割を果たします。ベンダーは、収益のより大きなシェアを獲得できるように、自社のソフトウェアとシステム製品に明確なビジネス価値を提供する必要があるからです。
• 新しいエレクトロニクス アーキテクチャ (バックエンドを含む) の特定の組織図を作成します。 自動車業界は、高度なエレクトロニクスとソフトウェアを提供および販売するために、内部プロセスを変更する必要があります。 また、車両関連の電子トピックについては、さまざまな組織設定を考慮する必要があります。 基本的に、新しい「階層型」アーキテクチャでは、現在の「垂直」セットアップを破壊し、新しい「水平」組織単位を導入する必要があります。 さらに、チーム内のソフトウェアおよびエレクトロニクス開発者の能力とスキルを拡大する必要があります。
• 個々の車両コンポーネントを製品としてビジネス モデルを開発します (特にサプライヤー向け)。 どの機能が将来のアーキテクチャに真の価値をもたらし、収益化できるかを分析することが重要です。 これは、競争力を維持し、自動車エレクトロニクス業界で価値の大きなシェアを獲得するのに役立ちます。 その後、製品、サービス、またはまったく新しいものであっても、ソフトウェアや電子システムを販売するための新しいビジネス モデルを見つける必要があります。

自動車用ソフトウェアとエレクトロニクスの新時代が始まると、ビジネスモデル、顧客のニーズ、競争の性質に関するすべてが根本的に変わります。 私たちは、これによって多額の収益が得られると信じています。 しかし、差し迫った変化を活用するには、業界の全員が自動車製造へのアプローチを再考し、自社の製品を賢明に設定（または変更）する必要があります。

この記事は、Global Semiconductor Alliance と協力して開発されました。

出所： habr.com