現代のネットワークは、SDVの基盤となっている

はじめに

SANJAY：こんにちは。Sonatus が提供するポッドキャストシリーズ「Driving Innovation 」の第1回へようこそ。私はプロダクト責任者のサンジェイ・カトリです。このシリーズでは、業界を「ソフトウェア定義車両（SDV）」へと導く技術やソリューションについてお話ししていきます。第1回となる今回は、SDVへの移行において、現代の車両ネットワークがいかに不可欠であるかについて解説します。 実際、それらはSDVのバックボーンであると言っても過言ではありません。SDVの本質は、ライフサイクルを通じてソフトウェアによって継続的に改善され、新機能が追加される車両を実現することにあります。例えば、あるOEMが「高速道路モード」機能を追加したいと仮定しましょう。この機能では、車が高速道路を走行していることをセンサーが検知すると、ドライバーの好みのドライブモード、シートの位置、オーディオ設定、および室内照明が自動的に選択されます。 現在の車載ネットワークでは、異なるドメインにまたがるこれらすべての機能を単一の統合された体験として結びつけることは困難であり、車両が生産・販売された後に実現できるようなことではありません。しかし、それこそがSDVが提供すべきパーソナライズされた体験なのです。こうした統合された体験を実現するには、柔軟かつ汎用性の高いネットワークが明らかに必要となります。 これは、現代のネットワークがクラウドデータセンターにおいて、データベース、ユーザーアカウント、課金、メッセージング、エンドユーザー向けGUIなどの異なるシステムやアプリケーションを統合し、シームレスなeコマース体験を実現してきたのと同じような仕組みです。そして、自動車がますます「車輪付きのデータセンター」のような存在になりつつある今、現代のネットワーク標準や慣行への同様の移行が求められています。それでは、私の同僚であるジェームズ・マーフィーにバトンを渡します。彼は、現代の車載ネットワークが具体的にどのような課題に対処し、どのように解決しているかについて解説します。

現在の車両ネットワークが抱える課題と限界

ジム：サンジェイ、ご紹介ありがとうございます。私はジム・マーフィーと申します。本日は、現在の車載ネットワークが抱える課題や制限、そしてイーサネット・バックボーンへの移行に伴う解決策についてお話ししたいと思います。まず第一の問題は、ネットワークが静的かつハードワイヤードであるため、既存のネットワークに新機能を統合することが非常に困難であるという点です。 2つ目の問題は、ネットワークが孤立していることです。そのため、異なるドメインが互いに切り離された状態で動作し、マルチドメインアプリケーションを実現するという可能性は、そのような環境下では著しく制限されてしまいます。既存ネットワークのもう一つの課題は、ネットワーク上で高い帯域幅を必要とする映像などの最新センサーに対応できるだけの帯域幅が、これらの技術では単純に不足していることです。さらに、帯域幅が制限されたネットワーク上で、リアルタイムアプリケーションにサービス品質（QoS）を提供することは非常に困難です。 セキュリティ面でも問題があります。車内には多種多様なネットワーク技術が存在し、数多くのセンサーやアクチュエータ、さまざまなデバイスがネットワークに接続されているため、攻撃経路が多すぎて車両を効果的に保護することが困難です。また、これら互いに異なる技術が存在するため、車両全体で統一されたセキュリティフレームワークを構築することも非常に困難です。 現在の車載ネットワークに関連する次の問題は、その物理的な構成にあります。ネットワーク自体が車両全体に重複して配置されているため、配線ハーネスは高コストで重く、複雑なものとなっており、その結果、非常に重く、製造コストの高い物理インフラとなっています。もう一つの問題は、より多くのマルチドメインアプリケーションをサポートするためにネットワーク間の相互接続を試みると、配線に関連する複雑さがさらに増すことです。 さらに別の問題として、ネットワーク自体の監視、トラブルシューティング、修復が困難である点が挙げられます。これは、ネットワーク技術の多様性、ひいては診断に必要なツールの多様性にも関連しています。そして、この多様性に伴い、車両全体にわたる診断の実施には運用上の複雑さが伴います。

現代の自動車は、こうした課題にどのように対処しているのか

JIM：では、現代の車載ネットワークはこうした課題にどのように対処しているのでしょうか？各ドメインごとに専用の物理インフラを備えていた状況から、車内のすべてのドメインをサポートする単一の物理インフラを備える状況へと移行しています。これにより、物理ネットワーク全体の配線コストを削減できるだけでなく、個々のネットワークコンポーネントの配線距離が短縮されるため、製造上の効率も向上します。 2つ目は、すべてのECUが他のすべてのECUからIP経由でアクセス可能になったことです。これにより、適用したいセキュリティ制限の範囲内であれば、どのECUも他のどのECUのデータにもアクセスできるため、複数のドメインにわたるアプリケーションがすべて実現可能になります。もう1つ興味深い点は、演算処理を、より少数の高性能ECUに集中させることができるということです。 つまり、以前は単一ドメイン内の専用プロセッサで実行されていた処理も、現在は共有プロセッサ上で実行できるようになりました。その結果、車両に搭載されるECU自体のコスト削減にも寄与できます。 また、サービス指向アーキテクチャ（SOA）の実現も可能になります。サービス指向アーキテクチャでは、個々のアプリケーションがネットワーク上のあらゆるサービスにアクセスできるため、データの可用性に応じてアプリケーションを実装できます。さらに、アプリケーションの分散や、車両内の異なる演算リソース間でのアプリケーション負荷分散といった、クラウドネイティブな概念も実現可能です。アプリケーション自体は標準的なIP技術を使用して構築されるため、多くの既存技術を活かして車両内で活用することができます。 例えば、ネットワークの末端や車両上に設置されたECUの一つとして、LEDコントローラが挙げられます。このLEDコントローラは、高性能ECUの1つ上で動作する集中型コントローラによって制御され、実質的にLEDシステムへ動画をストリーミングする形となります。したがって、こうしたアプリケーションをサポートするために、多くの既知の技術を再利用することが可能です。 さて、これらすべてのデータを単一のインフラストラクチャに移行すると、特定の課題が生じます。これは、重要度の異なるデータが混在することになるためです。つまり、リアルタイムデータがバルクデータや一般的なデータと混在することになるため、これに対処するためのプロトコルが必要となります。IEEEは、タイムセンシティブ・ネットワーキングの標準化を行っており、これにより、ネットワーク上で特定のプロトコルを実行したり、特定の技術を使用したりして、リアルタイムトラフィックを他の低優先度トラフィックと並行してサポートすることが可能になります。 最後に、高帯域幅環境が整っており、10BASE-T1Sからギガビット・イーサネットに至るまであらゆる規格が利用可能です。この高帯域幅を活用することで、ビデオなどの高帯域幅デバイスをサポートするだけでなく、リアルタイムのQoS要件を満たすことにも役立てることができます。

MACsecによるネットワークのセキュリティ確保

JIM：先ほど触れたように、現在、車両内にはさまざまなデバイスがネットワークに接続され、ネットワークリソースを利用しているため、新たなセキュリティ上の課題が生じています。ネットワークのセキュリティ対策が不十分だと、安全性、プライバシー、盗難に関連する問題にさらされることになります。 幸いなことに、イーサネットにはセキュリティ対策の長い歴史があり、MACsec（IEEE 802.1AE）と呼ばれるプロトコルを通じてこれに対応しています。これは既存の有線ネットワークで採用されている実績のあるセキュリティソリューションです。このプロトコルは、データの完全性と機密性を確保し、不正アクセスを阻止します。また、LANセグメントを保護します。 これはエンドツーエンドの技術ではありません。そのため、各LANセグメントは「接続アソシエーション」と呼ばれるものを形成します。これは一連のチャネルで構成されており、そのセグメント上の送信者ごとに1つのチャネルが割り当てられます。これらのセグメントのいずれかにMACsecが導入されると、ネットワークを流れるデータは盗聴されることがなくなり、完全性も保証されます。つまり、他のデバイスによるなりすまし攻撃を受けることはありません。 さらに、デバイスは認証を受けなければネットワークにアクセスできません。MACsecは、認証、認可、および鍵管理に802.1Xを使用します。802.1Xもまた、例えば企業のWi-Fi環境などで広く利用されている、実績のあるセキュリティソリューションです。 802.1X を使用することで、ネットワークに接続するあらゆるデバイスの認証や身元を確認することができ、これにより、身元に基づいてデバイスにポリシーを適用できるという概念である「アイデンティティベースのネットワーキング」の可能性が広がります。さらに、イーサネットスイッチは、認証済みのクライアントに適用できるアクセス制御リスト（ACL）などの追加のセキュリティ機能を提供し、ネットワーク上での送信が承認されたトラフィックのみを生成するように保証します。 また、このネットワークは、重要度が異なるアプリケーションの混在にも対応しています。

混合重要度

JIM：では、実際の「混合重要度」とはどういう意味なのでしょうか？あるいは、「重要トラフィック」とは何でしょうか？ クリティカルトラフィックとは、本質的にリアルタイムな性質を持つトラフィックのことで、つまり、高い優先度、低遅延、そして損失がほとんどないか全くない状態で配信されなければならないトラフィックを指します。イーサネットネットワークでこれを実現する方法は、すべてのハイパフォーマンストラフィックやリアルタイムトラフィックをサポートするのに十分な帯域幅があるという事実を活用し、インジェス側でそのトラフィックを制御することで、高優先度のトラフィックを送信するための帯域幅が常に確保されるようにすることです。 さらに、ネットワーク内の各エグレスポイントにスケジューラ（クレジットベースのスケジューラやタイムアウェアスケジューラなど）を設置し、トラフィックをスケジューリングすることで、ネットワーク内の他のベストエフォート型トラフィックよりも優先的に処理されるようにします。これにより、レイテンシを低い値に抑えることができます。 ただし、トラフィックを実際に分類していなければ、この仕組みはうまく機能しません。さらに、トラフィックのポリシングも必要です。そのため、ネットワークへの入力時（Ingress）に、さまざまなパケットフィールドを用いてトラフィックを高優先度トラフィックとして分類し、その特定のフローに割り当てた帯域幅内に収まるよう、トラフィックのポリシングを行います。 そしてもちろん、すべてのインターフェースの出口側では、レイテンシを低い値に保つよう優先順位に基づいてスケジューリングを行います。したがって、これらすべてを機能させるためには、一元的に管理されたネットワークが必要です。一元管理が必要な理由は、ネットワーク管理システムがネットワーク内のすべてのTSNフローを把握している必要があるためです。つまり、ネットワークを包括的にプロビジョニングする必要があるのです。

一元化されたネットワーク管理

JIM：第二に、動的なネットワーク制御プレーンが必要です。これにより、「ソフトウェア定義車両」の真価を実現できます。つまり、新しいアプリケーションが登場したり、実地で問題が見つかったりして、それらに対処するためにネットワークの挙動を変更したい場合、いつでもネットワークをアップグレードできるようになるのです。 しかし、これは今日のデータセンターで見られるような典型的なソフトウェア定義ネットワークとは異なります。なぜなら、車両には安全性やその他の重要な要件があり、構成をいつでも自由に変更することはできないからです。したがって、安全な方法で実施する必要があり、また、車両の既存の厳格な起動時間要件を確実に満たす方法で行わなければなりません。 車両本体とそのネットワークは、クラウド管理される必要があります。クラウド管理がなければ、実稼働中の車両をアップグレードすることは非常に困難だからです。 さらに、クラウド管理された一元化されたネットワークを持つことで、診断も簡素化できます。車載ネットワークコントローラーがネットワーク内のすべてのフローや、それらがどのスイッチを経由しているかを把握しているため、問題が発生した場合は、この構成に基づいて、どのスイッチからどの統計情報を収集すれば問題のデバッグに役立つかを特定できるからです。 また、パケットフローの確認、ネットワークのスニッフィング、その情報の分析など、さまざまな処理を行うことも可能です。

結論

SANJAY：ありがとう、ジム。ご覧の通り、現代の車載ネットワークは、ソフトウェア定義車両（SDV）が目指す多くのことをすでに実現しています。つまり、エンドユーザーに包括的な体験を提供するマルチドメインアプリケーションを通じて、顧客にシームレスな体験を提供できるということです。では、OEMや消費者にとってのメリットは何でしょうか？ まず第一に、OEMにとっては、よりシンプルでコスト効率の高いネットワークがメリットとなります。これにより、生産終了後であっても、非常に効率的かつ費用対効果の高い方法で新機能の追加や車両の変更が可能になります。エンドユーザーにとっては、ADAS、IVI、ドライブトレインといったマルチドメイン機能を活用し、これらすべてを統合することで、よりパーソナライズされ、安全で便利な体験を、車内全体でシームレスに得られるということです。 以上で、『Driving Innovation 』の第1回は終了となります。今後のエピソードでは、これらのトピックについてさらに深く掘り下げていきますので、どうぞお楽しみに。ありがとうございました。