画像
Darren Buttle
Darren Buttle
Head of RTA Solutions at ETAS Germany
画像
Sam Gold
Sam Gold
Senior Manager, Automotive Digital Marketing at Renesas Electronics Europe

1.1 はじめに

従来の車両設計からC.A.S.E.(次世代車両のConnectivity, Autonomous, Sharing, Electrification)への開発傾向として、車内での全体的な演算性能と通信負荷の指数関数的増加が要求されています。

画像
CASE: Connected, Autonomous, Shared, Electric vehicle
図 1 Case:Connected, Autonomous, Shared, Electric vehicle

C.A.S.E実現の上で必要な演算能力の達成と複雑なネットワーク形成は、従来の分散型E/Eアーキテクチャでは非常に多くのECU(電子制御ユニット)が必要になりケーブルハーネスの複雑さと重量の両方がそれに応じて増加し、また全体的な消費電力が増加しコストが高くなるため、実現困難なものとなります。

画像
E/E architecture today and tomorrow
図 2 E/Eアーキテクチャの現在と未来

したがって、物理ECUの数を増やすことなくC.A.S.Eへの移行することが重要な課題の1つとなります。この課題を解決するための鍵がハードウェアによってサポートされている新しいソフトウェアプラットフォームです。自動車メーカが既存資産を利用せず新たなゾーンECUを開発するのであれば初期よりドメイン/ゾーンアーキテクチャを採用可能です。しかしながら、実際には多くの自動車メーカは、1つのECUが1つの車両機能に対応する既存のE/Eアーキテクチャからゾーンアーキテクチャへの移行において、全てのSW開発を一から始めるわけではなく投資を抑えるため既存ECUの SW資産を活用します。

1.2 ゾーンアーキテクチャ実現の課題

ゾーンアーキテクチャでは、多数の機能とサービスを一つのECUへと統合します。ネットワークのコンセプトにおいて、帯域幅、リアルタイム性、および最大遅延に対する高い要求に対処する必要があり、加えてゾーンECUとしては、ゾーンアグリゲーター、コントローラー、またはプロセッサーとしての複数の機能を実行する高度なパフォーマンスが必要となるのは明らかです。一方で、安全でセキュアなアプリケーション運用に伴うFFI(Freedom from Interference)の確保や、リアルタイム動作の維持と内部ネットワークのルーティングアクセラレーションのサポートが不可欠です。

最新のECUでは、SWコンポーネントを基にした統合モデル、時間的および空間的分離、セーフティとセキュリティのための多数のメカニズム、クラスタソフトウェア構成による部分的な更新等を提供するAUTOSAR(AUTomotive Open System ARchitecture)クラシックソフトウェアアーキテクチャを採用することが予定されています。

ECU SWはOEM(アプリケーション)、Tier1(ミドルウェアと統合)、Tier2(MCAL)、サードパーティ(AUTOSAR BSW、OS、セキュリティファームウェア等)のように複数のメーカ、サプライヤによって開発されます。上記複数のメーカ、サプライヤによる複数のSWを統合することは、すでに今日では重要な開発工程の一つです。ただし、ゾーンECUの機能統合には以下の課題があります。

  • 複数ベンダーのアプリケーション統合の責任は誰にあるか?
  • ECUに障害が発生した場合、誰が責任を負うか?複数のECUシステムのセキュリティバリアを維持するためにはどうすればよいか?複数のベンダーがどのようにIPを保護するか?
  • 誰がデバックのための原因解明を行うか?
  • 小さな変更であってもECU全体に対する再テストに多くの工数が必要

これらの課題は、ハイパーバイザを使用し、一つの物理ECUを複数の仮想ECUに変換することで解決します。AUTOSARでは、各仮想ECUは、COMおよび仮想ネットワークを介して他の仮想ECUと通信する個別のECU(EcuExtract)です。 ハイパーバイザによる統合では、各仮想ECU(=VM: Virtual Machine)の独立性が高く、次のような利点が挙げられます。

  • 各VMは個別にコンパイルされ、リンクされる。
  • 各VMは独自のRTEを持つ。1つのRTE構成を変更しても、システム全体を再構築する必要はない。
  • 各VMはプロセッサハードウェアへの仮想アクセスが可能。
  • 1つのVMに変更を加えても、必ずしもシステム全体を再テストする必要はない。
  • システム全体から独立して1つのVMを再起動できるため、同じECU上の他の(関連のない)機能のダウンタイムを最小限に抑えること可能。

1.3 ゾーンアーキテクチャ – HW解決策: RH850 U2A/U2B

次世代ゾーン・統合型ECUに向けたRH850/U2xハイパフォーマンスマイクロコントローラー製品は、ハイパーバイザHWサポート、SoC(U2Bのみ)、セーフティとセキュリティ機能に対してのFFIの実現など、HWの主要機能をサポートします。さらに、高性能なNoC (Network on Chip)構造により、周辺機能及びメモリアクセス関連の統合された各アプリケーションへのリアルタイム動作を保証します。

Renesas のRH850/U2A MCU(Micro Controller Unit)は、複数のアプリケーションを動作させることができる高性能マイコンへの要望の高まりに対応するため、ハイエンドボディやシャーシアプリケーションを意識したクロスドメインプラットフォームとして設計されています。28nmプロセステクノロジーに基づく32ビットRH850/U2A MCUは、ルネサスのシャーシ制御用RH850/Pxシリーズおよびボディ制御用RH850/Fxシリーズの主要機能に基づいて構築されており、高いパフォーマンスを実現します。

画像
RH850/U2A block diagram
図3 RH850/U2A構成図

RH850/U2B ファミリーは、RH850/U2Aの長所に基づいた設計により、次世代の革新的な車載E/Eアーキテクチャへの課題を解決する各種機能を有しています。 最大32MBの新しい領域のパフォーマンスとメモリ統合を備えたRH850/U2Bは、RH850/U2Aシリーズの上位互換として、次世代の車載統合プラットフォームコンセプトにおいての増大する課題を解決しつつ、高いコストパフォーマンスを実現します。

画像
RH850/U2B Block Diagram
図 4 RH850/U2B構成図

H850/U2x MCUには、複数のASIL-D SWパーテーション統合を実現するための最新HWサポートテクノロジーが搭載されています。

  • ハイパーバイザHW支援機能による高性能ハイパーバイザOSを実現(高速コンテキスト切り替え、HV割り込みコンセプト)
  • Quality of Service (QoS):バスマスターの全ての帯域幅消費を防止することで、全てのバスマスターの遅延監視及びアクティブレギュレーション機能の最小帯域幅での動作を保証。(U2Bのみ)
  • メモリ保護ユニット (MPU): メモリ及び他リソースへのバスマスターからのアクセスを高度に細分化
  • ガード機能コンセプト: 周辺メモリ及び周辺モジュール用の高度で柔軟なスレーブガードシステム
  • セーフティ: SWパーテーションレベルでの個別処理を保証するための複数の個別エラー出力信号
  • セキュリティ: 競合せず、リアルタイム性を伴う安全でセキュアな通信のためのASE128ロックステップモジュールの複数インスタンス
  • No-wait OTA: 個々のSWパーテーションの独立した更新を保証するためのフラッシュバンクのバックグラウンド処理

1.4 ゾーンアーキテクチャ – SW解決策 – RTA-HVR

ETASのハイパーバイザであるRTA-HVRは、車両の厳格な安全性とセキュリティ要求を満たすべく、RH850/U2xへ最適なSWを提供します。RTA-HVRは、RH850/U2xファミリーのハードウェア仮想化機能を使用して複数のVMを生成します。各VMは1つ以上の仮想CPUコア、メモリ領域部分、周辺領域のセットを持ちます。

各VMの「ゲスト」は、独立してコンパイル及びフラッシュ書き込み可能なECUイメージであり、サードパーティによってビルドが可能です。RTA-HVRは、「ベアメタル」及びAUTOSARクラシックプラットフォームのゲストに対応します。

RTA-HVRは、柔軟なVMから物理CPUのコア割り当てまで対応します。VMが1つ(または複数)のCPUコアに固有的にアクセスできる際、VMスケジュールオーバーヘッドはゼロになります。複数のVMがCPUコアを共有する場合、以下のいずれかを選択します。

  • 静的に構成されたラウンドロビンスケジュール 又は
  • RH850/U2xのバックグラウンド割り込みによって駆動される動的予約スケジューラー

RTA-HVRは、MPUとガード機能を使用して、各VM間(各VMのメモリと周辺領域の分割)を空間的に分離します。

さらに、RTA-HVRは、「仮想デバイス拡張」(VDE)と呼ばれるメカニズムを提供し、ECUインテグレーターは特定のゾーンECUの仮想周辺コントローラーと物理周辺コントローラー間の割り当てをカスタマイズすることができます。VDEは、VM間で周辺機能を共有するための安全な方法を提供します。(例:周辺機能を必要とするVM数がハードウェア内の物理周辺機能数を超える場合)典型的な例としては、Ethernet Controller, HW Security Module, Watchdogまたは下記に示すようなCAN Channelの追加が挙げられます。

画像
VDEs also allow the creation of fully virtual peripherals devices for optimized inter-VM communication channels
図5 VDEを使用すると、VM間通信チャンネルを最適化するための完全な仮想周辺デバイスを作成可能

1.5 Zone-ECU Virtualization Solution Platform

複数のアプリケーションの統合に焦点を当てたゾーンECUの試作/開発でお客様をサポートすべく、ETASとルネサスは、Zone-ECU Virtualization Solution Platform を開発しました。

このプラットフォームは、ルネサス製RH850/U2xの HW機能とETAS製RTA-HVRを組み合わせ、ETASのRTA-CAR AUTOSAR Classic PlatformとPC上で動作するインタラクティブなツールを使用したプラットフォームです。

画像
Zone-ECU Virtualization Solution Platform Laboratory setup
図6 Zone-ECU Virtualization Solution Platform セットアップ

Zone-ECU Virtualization Solution Platformは、Easy to Startをサポートする開発プラットフォームとしてRH850/U2x MCU用の構成/構築済SW(ベンチマーク環境と同等なお客様が個々のゾーンECUプロジェクトの設計精査を迅速に開始可能なデモンストレーターSWを含む)を提供します。The Zone-ECU Virtualization Solution Platformは開発工数、コスト、及びリスクの削減に貢献します。

2. 概要

  • Zone-ECU Virtualization Solution Platformは、新たなE/Eアーキテクチャの開発又は検討を対象としたECUの開発、展示、ベンチマークをサポートする包括的なパッケージです。
  • Zone-ECU Virtualization Solution Platformは2022年4月に“SW-first” Renesas Winning Combinationとしてリリース予定です。

Log in or register to post comments