車はもはやソフトウェアで定義されるのか? ドメインアーキテクチャとSDV変革

電気自動車技術
作成: 14 10月 2026

100を超える制御ユニットを少数のゾーンコントローラーに集約するこのアーキテクチャにより、クルマのアイデンティティはもはや鋼ではなくコードから生み出されています.

このページを共有する

はい、現代の自動車の挙動、機能、性能キャラクターは、今やまずソフトウェアによって定義されています.ソフトウェア定義車両(SDV)と呼ばれるこの変革は、車両の電子アーキテクチャをECUの集積からドメインおよびゾーンコントローラーへと移行させることで、ハードウェアとソフトウェアを分離し、配線重量からOTAアップデートに至るまであらゆるものを作り変えています.

ハイライト

今日の車両には 100以上の コントロールユニットが搭載される場合があります.新しいアーキテクチャはこの数を 最大20% 削減することを目指しています.
ドメインアーキテクチャは機能別に、ゾーンアーキテクチャは物理的な位置によって構成します.
ゾーン型トポロジーでは CAN XL(最大20 Mbps) やギガビットEthernetなどの高帯域幅バックボーンが使用されています.
OTAアップデートは、ハードウェアとソフトウェアの分離によって可能となるSDVの基本機能です.
移行は段階的です.最初の領域はボディドメインであり、ADAS、パワートレイン、シャーシはより長い期間、既存の構造にとどまることができます.

ソフトウェア定義車両とは正確には何か?

定義は明確です.ソフトウェア定義車両とは、その機能と挙動が主にハードウェアではなくソフトウェアによって決定される車両です.従来の自動車では、ある機能はその機能専用に製造されたハードウェア部品によって定義されていました.SDVでは、同じハードウェアが、その上で動作するソフトウェアによって異なる機能を担うことができます.車両の販売後でも、新機能の追加、挙動のキャリブレーション、不具合の遠隔修正が可能です.

現在のE/Eアーキテクチャは100以上のコントロールユニットで構成されています.次世代の構造は、コントロールユニットの数で最大20%、材料とハードウェアで最大10%の節約を実現します.
Bosch Mobility、E/Eアーキテクチャ評価

この文が示す数字は、変革の規模を要約しています.問題はコントロールユニットの数だけではありません.各ECUはそれぞれの配線、それぞれのソフトウェアスタック、そしてそれぞれの検証負担をもたらします.SDVのビジョンは、この分散した構造を、ソフトウェアが単一の一貫したレイヤーで管理できるシステムへと変換することです.そのためには、電子アーキテクチャの根本的な再構築が必要です.

ECUからドメインアーキテクチャへ:機能別のグループ化

自動車のあらゆる小さな機能が個別の電子制御ユニット(ECU)を持っていた時代は、配線ハーネスを管理不能なものにしました.ドメインアーキテクチャはこれに対する最初の体系的な回答となりました.車両のエレクトロニクスを、ADAS、インフォテインメント、パワートレイン、ボディエレクトロニクス、シャーシ、安全といった大きな機能領域別に構成するものです.各ドメインは通常、独自のプロセッサ、ソフトウェアスタック、通信インターフェース、センサーおよびアクチュエーターを持ち、ドメインコントローラーによって管理されます.

この構造は、ECUのカオスに比べて大幅な整理をもたらしました.しかし、SDVの目標が拡大するにつれ、ドメインアーキテクチャの限界が明らかになりました.特に、自動運転機能が生み出すセンサーデータは、従来のCANネットワークの帯域幅を限界まで押し上げました.さらに、各ドメインが独自の演算リソースを持つことは、配線ハーネスを複雑なままにし、ソフトウェアが車両全体でスケールすることを困難にしました.

ゾーナルアーキテクチャ:組織化が機能から物理的な位置へ移行

ゾーナルアーキテクチャの考え方は従来の常識を覆します.電子機器を機能別ではなく、車両内の物理的な位置に基づいてグループ化します.車両は左前、右前、左後、右後、キャビンなどのゾーンに分割され、各ゾーンにはゾーナルコントローラーが配置され、そのゾーン内のセンサー、アクチュエーター、電源配電を集約し、中央の高性能処理プラットフォームと通信します.

特徴	ドメインアーキテクチャ	ゾーナルアーキテクチャ
組織化の原則	機能別(パワートレイン、ADAS、ボディなど)	物理的な位置別(左前、右後など)
処理リソース	ドメイン固有の処理	集約された中央/分散処理
配線	複雑で長いワイヤーハーネス	配線と重量の削減
ECU数	多数のECU	少数のゾーナルコントローラー+中央コンピューター
ソフトウェアの柔軟性	SDVにはスケールが困難	高いソフトウェアの柔軟性

得られるメリットは具体的かつ測定可能です.ワイヤーハーネスの重量が減り、ポイントツーポイント接続が減り、車両アーキテクチャとシステム検証の作業が簡素化されます.さらに重要なのは、センサーとアクチュエーターの設計が中央処理ノードから独立することです.これにより、ハードウェアとソフトウェアの更新サイクルが分離され、1つのセンサー設計を複数の車両世代にわたって使用できるようになります.

ゾーナルコントローラーの役割とは?タスク分担とハードウェアとの関係

Zonal mimaride kablolar kısaldıkça araç hafifler, sigortalar yerini yarı iletken anahtarlara bırakır ve güç artık bölge bölge yönetilir.

ゾーナルアーキテクチャの鍵となるのは、多数のアクチュエーターとセンサーを中央処理ECUに接続する役割を担うゾーナルコントローラーです.このコントローラーは単なるデータ収集ボックスではなく、リアルタイム制御ループを自身で実行でき、ゾーン内のデバイスを管理し、フィルタリングされ優先順位付けされたトラフィックをバックボーンへ送信します.Tiを来源とするエンジニアリング評価によれば、ゾーンモジュールのMCUは、高いリアルタイム性能、大容量メモリ、異なるASILレベルに対する仮想化サポート、バックボーンへの高速通信、そしてCAN FDやLINなどの低コストで多数のエンドインターフェースを提供する必要があります.

電源配電はどのように分散化されるのか?

ドメインアーキテクチャでは、電力はヒューズとリレーを備えた中央電源配電ボックスから供給されます.ゾーナル構造では配電が分散化されます.1本の電源ハーネスがバッテリーからゾーンへ引かれ、ゾーンモジュールがそのゾーン内のモジュールに電力を分配します.短い電源ケーブルは、そのまま重量とコストの削減を意味します.さらに、ヒューズの代わりに半導体ベースのスマートヒューズが採用されます.I²t特性を持つハイサイドスイッチにより、ヒューズのばらつきが減少し、より最適化されたケーブル断面積が実現します.MCU、ハイサイドスイッチ、トランシーバーで構成されるスマート電源配電ボックスは、ソフトウェアによって設定が行われるユニットとなり、同じボックスを負荷に応じて調整しながら各ゾーンで使用できます.

物理I/Oと論理I/Oの分離

ゾーナルモジュールは、複数のECUの論理入出力機能を一箇所に統合することで配線の複雑さを軽減します.一方、センサーとアクチュエータの物理的な位置はそのまま保たれます.さらに一歩進むとエッジデバイスは「スマート」になります.ローカル回路が状態情報を保持し、障害診断を実行するのです.CAN FD Lightのような簡略化されたプロトコルは、一部のエッジノードにおける個別MCUの必要性すら解消できる可能性があります.ハードウェアは固定のままでタスクがソフトウェアによって定義されるこの分離こそが、SDVのエンジニアリング基盤です.

ゾーナルアーキテクチャ車におけるデータバス: 帯域幅、タイミング、サイバーセキュリティ

センサーフュージョンとAIワークロードは、ゾーナルトポロジーを高帯域幅のバックボーン上に構築することを必須とします: PCIe、 最大20 Mbpsの データ速度に到達し、既存のCAN互換性を維持するCAN XL、そしてギガビットイーサネットです.本当の課題は帯域幅以上にタイミングにあります.短い制御メッセージ、ADASセンサーデータ、インフォテインメントトラフィックは、それぞれ大きく異なる遅延、ジッター、同期の要件を持っています.大まかな目安としては、オーディオにはミリ秒レベル、パワートレインとシャーシ制御にはマイクロ秒レベルの遅延目標が適用されます.

これらの異なるトラフィッククラスを単一のネットワークで伝送するために、イーサネットベースのTime-Sensitive Networking (TSN)が解決策として浮上します.時間同期 (IEEE 802.1AS)、時間感応型トラフィックシェーピング (802.1Qbv)、エクスプレストラフィック (802.3br)、フレームプリエンプション (802.1Qbu)、冗長性 (802.1CB) などの規格は、重要なデータに決定論的な遅延保証を提供します.安全面ではISO 26262への対応、冗長な通信経路、安全パーティショニング、障害検出が、サイバーセキュリティ面ではISO/SAE 21434規格、UNECE規制、MACsecのような低レベルの暗号化・認証メカニズムが決定的な要素となります.ゾーナルアーキテクチャはネットワークを中央集権化するため、イーサネットベースの攻撃手法も実行可能になります.セキュリティ侵害が発生した場合、入出力と処理の分離という概念の崩壊は、個別に評価すべきリスクです.

ハードウェアとソフトウェアの分離はどのようにOTAアップデートを可能にするのか?

OTAアップデートは、ほとんどのSDVの議論で真っ先に思い浮かぶ機能ですが、それ自体は一つの能力ではなく、アーキテクチャの帰結です.ソフトウェアがハードウェア抽象化層 (HAL) を通じて特定のチップから分離されず、車両機能が独立した、再利用可能な、疎結合なサービスに分割されない限り (サービス指向アーキテクチャ、SOA)、中断のないアップデートは実現できません.この分離には、異なる安全性レベルのソフトウェアを互いに隔離することも含まれます.

具体的に言うと、ゾーンアーキテクチャ、OTA/FOTAアップデート、常時のクラウド接続により、高レベルのソフトウェアメンテナンスの管理をメーカーに委ねながら、リアルタイムの制御ループをゾーンモジュールに移行することができます.使用されていないモジュールの電力供給を強化するといった細かな調整も、この構造では容易になります.結局のところ、電気自動車のソフトウェアとは、単なるアップデートの経路ではなく、車両の機能、安全システム、そしてパフォーマンス特性を決定づける定義レイヤーなのです.車両は、車輪の上に載った分散型データセンターのような姿になりつつあり、その価値連鎖はソフトウェア、処理能力、システムアーキテクチャに支えられています.

移行はどのくらいの速さで進み、ゾーンアーキテクチャだけで十分なのか?

移行は段階的に行われます.ボディ(Body)ドメインは多数の分散型アクチュエータとセンサーECUを含むため、ゾーンアーキテクチャへ移行する最初の領域となります.一方、ADAS、パワートレイン、シャシー制御の移行は、安全性に極めて重要な性質を持つため、より時間がかかる可能性があります.2017年以降のMCAL、BSW、アプリケーションレイヤーにおける進化は、これが単なる技術プロジェクトではなく、業界全体の考え方の転換であることを示しています.

バランスの取れた見方も必要です.ゾーンアーキテクチャは車両を物理的に再編成しますが、論理面およびソフトウェア面(SOA、HAL、サイバーセキュリティ)は別途解決する必要があり、配線を組み替えただけでは車両がソフトウェア定義になるわけではありません.市場規模の推計も、対象範囲の定義によって大きく変動します.E/Eアーキテクチャ市場に関する異なる数値は、何を(処理プラットフォームのみか、それとも分散型エレクトロニクス全体か)算入するかによって測定方法が異なることに起因します.また、移行の当事者である半導体メーカーおよびソリューションプロバイダーが、この変革に当然ながら利害関係を持っていることも忘れてはなりません.

結論は、明確なエンジニアリングの均衡です.車両のソフトウェア定義は、単一のソフトウェアプロジェクトではなく、ドメインコントローラーとゾーンコントローラーに基づく新しいハードウェア構成、分離されたソフトウェアレイヤー、そして決定論的で安全なデータバックボーンが同時に存在することによって初めて可能になります.OTAアップデートはこの統合された構造の最も目に見える成果にすぎず、真の革命は、車両のハードウェアがその役割の定義をソフトウェアに委譲することにあります.