クルマはController Area Network(CAN)、Local Interconnect Network(LIN)、FlexRay、Media Oriented Systems Transport(MOST)、イーサネットなどの通信プロトコルを使用して、さまざまな電子制御ユニット(ECU)間の通信を行っています。例えば、ボディ・コントロール・モジュール(BCM)はLINを使用して雨センサと通信しています。同様に、オンボード診断スキャン・ツールはCANまたはイーサネットを使用して車内の複数のECUと通信しています。

こうしたECUは、通信やデータ交換のために異なるドメイン間やプロトコル間でブリッジを行う方法を必要とします。ここで役割を果たすのがゲートウェイです。図1が示すように、ゲートウェイはさまざまなECUを接続し、意図した受信者にデータを転送する前に、そのデータをあるプロトコルから別のプロトコルに変換します。

図1:ゲートウェイを示す代表な車載ネットワーク構成

図2はゲートウェイ・モジュールの代表的なブロック図です。ここでわかるように、ゲートウェイは通信インターフェイス物理層(PHY)、プロセッサ1個、対応する複数のパワーマネージメント・デバイスで構成されています。

図2:車載ゲートウェイのブロック図

クルマの「つながり」が増加するにつれて、より多くのデータが必要になることから、クルマではイーサネットが主流になっています。それに伴い、ゲートウェイはニーズに対応して進化を遂げてきました。従来のゲートウェイがより小型でシンプルなマイクロコントローラ(MCU)をコントローラとして使用するのに対して、最近のゲートウェイはプロセッサを使用しており、場合によっては補助的なMCUが併用されます。プロセッサとMCUの違いはメモリにあります。プロセッサは外付けメモリを使用しますが、MCUはすべてをオンチップで備えています。

なぜプロセッサにシフトしているのでしょうか。理由の1つはサポートの観点から説明できます。多くのプロセッサはイーサネットを統合するとともに、イーサネットをサポートするソフトウェアを備えています。メモリの大きいプロセッサはLinuxなどの一般的なオペレーティング・システムを駆動できることから、ポータビリティの向上と開発時間の短縮を可能にします。さらに、ゲートウェイ機能を統合しているECUもあります。例えば、TIのJacintoファミリのマルチコア・プロセッサの使用により、ECUの機能のためのタスクをゲートウェイ機能から分離することができます。タスクの分割によって各コアの負荷が小さくなり、クロックはゲートウェイのリアルタイム要件を満たしながら低速動作が可能になります。

MCUからプロセッサへのシフトのもう1つの理由が、異なる通信ドメイン間のデータ変換に必要なプロセッシング能力の量です。イーサネットはCANあるいはLINのいずれよりも大幅に高速で、シングル・ツイストペア・ケーブル100BASE-T1の採用が車載イーサネットで主流になっています。ゲートウェイは100Mbps、最終的にはギガビットの速度に対応できなければなりません。さらに、ゲートウェイによっては8個以上のCANポートや10~12個のイーサネット・ポートを備える可能性もあります。それに加えて、通信のタイムクリティカルな性質により、MCUよりも多くのプロセッシング能力が必要になります。

すでに述べたように、多くのゲートウェイは1個のプロセッサ以上に、各プロトコルに対して複数のポートを備えています。外付けイーサネット・スイッチはイーサネットに対応可能ですが、CANやLINなどの他のプロトコルには別のソリューションが必要になります。補助的なMCUはゲートウェイへのこうした複数のポートの提供やプロセッサへのデータ転送が可能であると同時に、プロセッサのコンピューティング能力を活用し、あるドメインから別のドメインへの複数のパケットの変換と転送を行います。

イーサネットやCANを使用する車載スタンドアロン・ゲートウェイのリファレンス・デザインは、イーサネットやCANに対応可能なゲートウェイ向けのビルディング・ブロックを提供します。このリファレンス・デザインはJacinto™ DRA710プロセッサ、2個のEthernetポート(100BASE-TXプロトコルと100BASE-T1)、2個のCANポート、関連の電源ツリーを搭載しています。

関連情報

※すべての商標はそれぞれの所有者に帰属します。
※上記の記事はこちらのBlog記事(2017年9月20日)より翻訳転載されました。
*ご質問はE2E Support Forumにお願い致します。

Anonymous