Other Parts Discussed in Post: TCAN4550-Q1

BLE(Bluetooth® Low Energy)を使用するパッシブ・エントリ-パッシブ・スタート(PEPS)車載システムでは、ドライバーが車の鍵の代わりに、車のアクセス・システムと通信を行うリモコン・キーを使って車に乗り、電気モーター(内燃エンジンの場合はエンジン)を始動します。ここでは、車載PEPSシステムに利用される通信バス・アーキテクチャの選択から実装例までをご紹介します。

図1は、車に搭載されるBLE PEPSの一般的なアーキテクチャです。このアーキテクチャは、中心になるスマートキー・モジュール1個と、サテライト・モジュール9個で構成されています。ここでは1つの例としてサテライト・モジュールを9個としていますが、実際に搭載されるサテライト・モジュールの数は異なります。図1からは、これらのモジュールが通信バスを利用して通信を行うこともわかります。

1:車載Bluetooth Low Energy PEPSアーキテクチャ

サテライト・ノードの内部

では、サテライト・ノードの内部はどうなっているのでしょうか。図2は、一般的なBLEサテライト・モジュールのブロック図です。このモジュールには、TIのSimpleLinkTMCC2640R2F-Q1』といったBLEシステム・オン・チップ(SoC)、電源、通信インターフェイス(通常はトランシーバ)が使われています。図2には、スマートキー・モジュールや車体制御モジュールなどの、PEPSシステムに関係する他のモジュールも示しています。


2:車載PEPSシステムのブロック図

通信バスの選択肢

車載PEPSシステムに利用される主な通信バス・アーキテクチャは、LIN(Local Interconnect Network)とCAN(Control Area Network)の2つです。CANにはさらに、Classical CANまたはCAN Flexible Data Rate(CAN FD)があります。LINとCANは両方とも、車載アプリケーションで広く使われている標準的な通信プロトコルです。LIN通信システムのボー・レートは最大で19.2Kbpsです。Classical CANでは1Mbps、CAN FDでは最大5Mbpsです。

LINとCANは両方とも、通信プロトコルを構築するベースにメッセージ・フレームを使用し、いずれも最大で8データ・バイトを転送することができます。LINでは8データ・バイトを含むメッセージ・フレームの長さが124ビットなのに対し、標準CANフレームまたはCAN 2.0フレームのメッセージ・フレームの長さは(フレーム間のスペースを含み、ワーストケースのビット・スタッフィングを想定して)135ビットです。そのため、LINのメッセージ・フレームの伝送には6.46msかかるのに対し、標準CANメッセージ・フレームの伝送には135µsしかかかりません。

LINCANのどちらを選択するか

この計算からわかるように、CANのメッセージ・フレームに比べてLINのメッセージ・フレームの伝送には時間がかかります。そのため、速い方が良いはずだと考えて、CAN通信バスを選択するかもしれません。しかし、CANバスは2線式通信バスですが、LINバスは1線式です。つまり、CANバスをベースとしたシステムはLINバスを使用するシステムよりも高コストになります。場合によっては、CANバスを選択するのがベストとは言えません。

それでは、2つのうちどちらの通信プロトコルを選択するかを、どのように決めればいいのでしょうか。1つの方法は、伝送が必要なバイト数が合計でどのくらいになるかを分析することです。BLEチップでサテライト・ノードに演算アルゴリズムが実装されている場合、伝送が必要なバイト数は少なくなるため、LIN通信でも十分でしょう。逆に、BLEチップが演算処理を行わず、単に測定したデータをすべてそのまま送信するとしたら、伝送が必要なバイト数はずっと多くなるため、CANアーキテクチャが必要になります。

もう1つ考慮しなければならないのは、消費電力です。LINバスをベースとしたノードは、一般にどの動作モードであってもCANバスよりも消費電力が低くなります。消費電力の具体的な数値は、それぞれのトランシーバのデータシートで確認できます。

実装例

TIの車載、Bluetooth Low Energy、カー・アクセス向けサテライト・ノードのリファレンス・デザインは、LINベースのサテライト基板の実装を示したものです。このリファレンス・デザインでは、BLE SoCとしてTIの『CC2640R2F-Q1』、LINバスのトランシーバとして『TLIN1029-Q1』を使用しています。

スマートキー・モジュールとBLEサテライト・モジュールの間でデータを大量にやり取りしなければならない場合は、Classical CANまたはCAN FDバス・アーキテクチャが選択肢になるのは明らかです。CAN FDコントローラとトランシーバを内蔵するTIの新しいシステム・ベーシス・チップ(SBC)『TCAN4550-Q1』を使用すると、簡単にCAN通信機能をサテライト・ノードに追加できます。コントローラとトランシーバが内蔵されていることに加えて、SBCは自己給電のため、電源デバイスを追加する必要がありません。SBCは、プリント基板上の追加部品に電力を供給する電圧源と、SoCモニタとして機能するウォッチドッグ・タイマも備えます。

図3に、『TCAN4550-Q1』の機能的メリットを活用したサテライト・ノードの実装例を示します。


3:『TCAN4550-Q1』を使用して簡単にCAN通信機能をサテライト・ノードに追加することが可能

図3では、『TCAN4550-Q1』の5V出力を、低VINリニア・レギュレータ『TLV733P-Q1』の入力に使用します。このレギュレータがBLE SoC 『CC2640R2F-Q1』に必要な3.3Vを生成するので、BLE SoCに電力を供給するための広VINレギュレータが不要になります。レギュレータの3.3V出力が『TCAN4550-Q1』のVIOにも使われるため、BLE SoCと『TCAN4550-Q1』の間で電圧レベルをシフトする必要がなくなることにも注目してください。『TCAN4550-Q1』のウォッチドッグ・タイマは、BLE SoCのソフトウェア実行を監視することもできます。このように高度に統合されたSBCのおかげで、BLEサテライト・ノード向けのコスト最適化されたソリューションを実現できます。

まとめ

設計エンジニアは、BLEテクノロジーを利用した次世代PEPSシステムを車に組み込むようになっています。PEPS要件に適合するために必要なノード数を最適化するという設計課題に取り組むとき、そのソリューションにおいて通信バス・アーキテクチャが果たす役割は重要です。通信機能にはLINまたはCANという選択肢があります。TIでは、BLE SoCと電源管理デバイスの他に、LINトランシーバや新たに導入したSBC『TCAN4550-Q1』により、デバイスを選択する上で豊富なポートフォリオを用意するだけでなく、車載プラットフォームの最適なソリューションを開発するための柔軟性を提供します。

 

参考情報

+『TCAN4550-Q1』の詳細はこちら

+TCAN4550-Q1 SBC概要:”How to easily upgrade to CAN FD using the TCAN4550-Q1.

+ボディ・エレクトロニクスおよびライティングの詳細はこちら

 

※上記の記事はこちらの技術記事(2019年6月11日)より翻訳転載されました。

※すべての登録商標および商標はそれぞれの所有者に帰属します。

※ご質問はE2E Support Forumにお願い致します。

Anonymous