View
216
Download
0
Category
Preview:
Citation preview
1April 2013
Technical Article
さらに進化するCAN
この数年、自動車業界では車載電子機器におけるデータトラフィックの増加に起因するネットワークのボトルネックが生じています。その分野において、より優れたネットワークソリューションのための新たな基盤となるのがCAN FDです。現在はネットワークを複数のバスに分割するなど苦肉の策が講じられてはいますが、それがコストの上昇を招いているという状況です。しかし、CANよりも高性能のFlexRayに切り替えれば、多額の投資コストが発生します。多くの開発者にとって、イベントドリブンのC ANからタイムトリガーのFlexRayに移行するには、従来の作業や考え方に対する大幅な変更も必要となります。
「変化」ではなく「進化」を
CANは約20年間、自動車業界において主力のバスシステムの座にありました。そのため、この分野にはすでに開発者の膨大なノウ
ハウが蓄積されています。バスの通信調停、メッセージの確認応答、イベントドリブン制御といったCANの既存概念はCAN FDにも受け継がれており、それらの専門知識はCAN FDのプロジェクトにも引き続き応用することができます。またCAN FDは、非常に柔軟に使用することができます。アプリケーションでは、ビットレートの向上やデータ長の拡張、あるいはその両方を生かすことができます。たとえば、トラックのようにバスの配線が長いアプリケーションで伝送速度をもう少し上げたいという場合は、最大で64バイトというデータ長を利用することによって極めて高いデータスループットを確保できます。
CAN FDはCANと同種の機能を多数装備していますが、プロトコルの拡張への対応とハードウェア/ソフトウェアに対する適合作業は、やはり必要です。特に、CAN FDのコントロールフィールドには、EDL (Extended Data Length)、BRS (Bit Rate Switch)、ESI (Error State Indicator) の3つのビットが新たに採用されて
～ 現状のCANからCAN FDへの移行まで ～
2012年3月、Robert Bosch GmbHは、新しいCANプロトコル「CAN FD (CAN with Flexible Data rate： 可変データレート対応のCAN)」を正式に発表しました。このプロトコルの新しい特徴として主に挙げられるのが、8バイトから64バイトへのデータ長の拡張と、データ伝送速度の大幅な向上です。CAN FDはその性能データから、高速CAN (1Mbit/s) とFlexRay (10Mbit/s) の間に位置づけられ、これらのバスシステム間のギャップを低コストで埋める理想的なプロトコルであるといえます。本稿では、CAN FDを利用した開発やシミュレーションに移行する際に必要となる変更とその影響を、ツールサプライヤーの観点から説明します。こうした変更は、ハードウェアから始まり、メッセージ内に含まれるデータフォーマット、そして各種通信レイヤーに至る多様なレベルで発生します。
2April 2013
Technical Article
います。EDLビットは従来のCANフォーマットのフレームとCAN FDフォーマットのフレームを識別するビットで、CAN FDフレームではレセッシブに、CANフレームではドミナントに設定されています。同じくBRSビットがレセッシブの場合は、データフィールド送出時のビットレートが高速に切り替わります。ESIビットはCAN FDノードのエラー状態の識別に使われます。さらに、DLC (Data Length Code) としてデータ長の拡張分をカバーする4ビット構成が追加されており、これを使用して12、16、20、24、32、48、64バイトのいずれかの値を設定します (図1)。
ツールサプライヤーの課題
CAN FDなどの新システム導入に際し、ソフトウェア開発ツールのサプライヤーが直面する課題は、顧客ベースで最初のCAN FDのECUが開発される時機を逸することなく、適切なツールを提供できるようにしておくことです。既存のテスト/シミュレーション環境にCAN FDを統合するには、ハードウェアからアプリケーションに至るさまざまなレベルで迅速に変更を行わなければなりません。また、通信ネットワークを記述するために、それに関連するデータベースも必要です。この状況で第一に考えるべきは、「CAN FDをモデル化するための最善策は何か？」ということです。有効データ長は最大64バイトですが、これを考慮するとPDUの抽出は必要でしょうか？PDU (Protocol Data Unit) はFlexRayで一般に使用されているだけでなく、AUTOSARシステム記述でもサポートされています。これらはCRCの詳細チェックなどの目的に使用するほか、Txトリガーとして利用することが可能です。基本的に、CAN FDをモデル化する際は、CANの分野で実績の
ある部分をできるだけ多く残すのが適切な手段です。たとえば、CAN FDを新しいバスシステムではなくCANの拡張として扱えば、既存のCANテスト/シミュレーションシステムはスピーディーに移行でき、ツールに必要な構成変更は比較的少なく済むようになります。テストスクリプトやデータベースを引き続き使用することも可能です。
次に、CAN FDのデータバイトを当初8バイトに制限できれば、自動車メーカーやサプライヤーは最初のプロジェクトを迅速に実施できます。DBCデータベースも、そのまま使用可能です。これらはCANアプリケーションで広く使われており、事実上の業界標準となっています。さらに、DBCはJ1939などのプロトコルでは、すでに64バイト長のデータを処理できます。
FPGAを用いた柔軟なハードウェアと互換トランシーバー
ソフトウェアツールの構成と、解析/テスト/ログ/シミュレーションといった主な用途を考えれば、車両のプロトコルスタックのほぼすべてのレイヤーでCAN FDへの適合が必要となることは言うまでもありません。物理的なレベルでは、ツールはバスへのアクセスに、必ずと言っていいほどネットワークインターフェイスを利用します。ネットワークインターフェイスはFPGAまたは標準のコントローラーチップのいずれかを利用して実装できます。標準のコントローラーチップは費用効果の高いソリューションですが、特定の機能セット以外には利用できないうえ、最初にCAN FD用のチップを用意しなければなりません。これに代わる方法で、より柔軟かつ迅速に利用できる手段、少なくともCAN FDの初期フェーズで利用可能な手段が、FPGAを装備したインターフェイスです。この技術によって、必要なリアルタイム性の要求を満たすだけでなく、64バイトのサポート等の新しい機能の提供やバグ修正が、ドライバーの更新によって行えるようになります。CAN FDに新しいトランシーバーが必要かどうかは、その特定のユースケースによって異なります。車載ネットワークの場合、実装される転送レートは2Mbit/sから4Mbit/sだと思われますが、ECUのフラッシュ処理では可能な限り高いレートが求められ、使用するCANトランシーバーによっては8Mbit/s以上というレートもあり得ます。ピギーバック上にトランシーバーを実装した構成可能なハードウェア、すなわち、小型の交換可能なプラグオンボード (図2) を使用すれば、将来のトランシーバーに柔軟なアプローチで対応できます。
図1：CAN FDのフレーム
3April 2013
Technical Article
既存ネットワークの再設計：CAN (FD)、LIN、FlexRay
新しいバスシステムを導入すれば、現在のネットワークプロトコルには当然、何らかの影響が生じます。LINネットワークではCAN FDの強みが発揮されないため、変更が生じることはまずありません。ただし、データ長が8バイトを超える場合、CANフレームのデータをLINフレームにコピーしただけでは、単純なTPルーティングは実装できないので注意が必要です。Fle xRayでは、状況が異なります。CAN FDの方がコストパフォーマンスに優れることから、イベントドリブンのアプリケーションが使用される場面では、常にCAN FDがソリューションとして推奨されます。一方、FlexRayの用途は限られており、使用されるのはクリティカルで決定論的な、リアルタイムのアプリケーションです。そのため、既存のCANシステムにおいては、FlexRayへの移行が発生する場合もあります。バス負荷の高さが50%程度のネットワークならば、CAN FDへの移行を検討する対象となります。C AN FDによって帯域幅が上がるため、バス負荷の高いネットワークを分割せずに済み、さらに、複数のネットワークを元の1つのネットワークに戻すことも可能です。その分のゲートウェイが不要となり、コストが削減され、ゲートウェイによるレイテンシーも解消するというメリットがあります。
CAN/CAN FDネットワークの混在に関するコンセンサスは、現時点では存在せず、基本的には自動車メーカーの意向次第です。C ANとC AN FDを混在させて実装する場合は、必ず何らかの措置を取ることが必要になります。たとえばFDで運用する場合、C ANノードはパッシブ状態でネットワークから切り離されている必要があります。それ以外の状態では、C ANノードがEDLビットによってフォームエラーを検出し、エラーフレームを送出するためです。
通信レベルでは多くの場合、フレームを図示し、そのフレーム内の特定データにアクセスできる解析ツールが開発者には必要です。このツールではCAN FDの新しいビットであるEDL、BRS、ESIを正しく解釈することが求められます。拡張されたデータ長についても同じことが言えます (図3)。CAN FDフレームの出力が必要な場合は、フレームをイベントとしてモデル化することにより、簡単に行うことができます。すなわち、CAN FDのビットを既存のCANイベントに追加し、有効データ長を長い方まで拡張すれば済むのです。CANフレームとCAN FDフレームの区別は、メッセージを表示する解析windowで必要となります。
CAN FDの上位レイヤー
さらに上のレイヤーで注目するのは、診断、ネットワーク管理 (NM)、トランスポートプロトコル (TP)、インタラクションレイヤー (IL)のモデルです。トランスポートレイヤー上のアプリケーションでは複数フレームが解釈されますが、アプリケーションレイヤーでは主にフレームではなくシグナルが扱われます。ネットワーク管理、インタラクションレイヤーのモデルは、いずれも各自動車メーカーの要求仕様によって決定されます。CAN FDにおけるデータ長の拡張は、インタラクションレイヤーとトランスポートレイヤーの両方に影響するため、この部分には修正が必要です。適切なインターフェイスを持つモジュール型ツールには、メーカー独自の機能の実装、または入れ替えが簡単に行えるのに加え、CAN FDに必要な拡張も簡単に実装できるという強みがあります。アプリケーションのレベルでは、アプリケーションを特定のプロトコルに依存せず、一貫してシグナルベースで設計していれば、開発者はスムーズに作業に移ることができ、自分のシミュレーションモデル、テストスクリプト、GUIなどを、ほぼ無修正でそのまま使用できます。
図2：CAN FD対応のバスインターフェイスとトランシーバーを実装したピギーバック
4April 2013
Technical Article
CANからCAN FDへの移行
CAN FD対応のECUとネットワークの開発において、先進的な解析/テスト/シミュレーションツールによるサポートは貴重な助けとなるでしょう。その機能は、個々のネットワークノードの解析から、ネットワーク全体のシミュレーションに至るまで多岐にわたります。こうしたツールにより、開発者は信頼できるシミュレーションデータに基づいて今後のバス負荷を予測し、たとえば、ネットワークを複数に分割すべきかということにも適切な判断を下せるようになります。開発フェーズでは、このツールは残りのバスシミュレーションを実行するために用いられます。このシミュレーションは入手できないサブネットワークやそのコンポーネントを代行するもので、シミュレーションされたノードは、後から段階的に実際のECUに置き換えられます。このシミュレーションはゲートウェイの役目も果たし、それによって新しいCAN FDネットワークと従来のCANネットワークとを接続することができます。この場合、既存のCANのECUに変更を加える必要はありません。
結論
FPGAを利用した柔軟なネットワークインターフェイスと、高性能の解析/テスト/シミュレーションツールを使用すれば、自動車メーカーおよびサプライヤーは、円滑なCAN FD開発に必要な、すべての要素を入手することができます。ここで説明したシステムは、各種のデータベース形式をサポートするとともに、シグナルおよびPDUレベルでの多彩な抽出を行うことができます。オープンなインターフェイスを使用することで、メーカー固有の仕様の実装が可能となります。ネットワークのシミュレーションと残りのバスシミュレーションが、開発プロセスのあらゆる場面で最適なテスト条件を約束します。
図3：CAN FDのシミュレーションおよびテストツール
Peter Decker 2002年、Vector Informatik GmbHに入社。現在、CANoe/CANalyzerのマルチバス開発分野のプロダクトマネージャー。
■ 本件に関するお問い合わせ先ベクター・ジャパン株式会社 営業部 （東京） TEL：03-5769-6980 FAX：03-5769-6975 （名古屋） TEL：052-238-5020 FAX：052-238-5077
E-Mail：sales@jp.vector.com
執筆者：
参考文献：
CAN FD specification V1.0, Robert Bosch GmbH
提供元：見出し画像/図1～ 3：Vector Informatik GmbH
リンク：CANのためのソリューションhttp://vector.com/vj_can_solutions_jp.html
ベクター・ジャパンhttp：//www.vector-japan.co.jp
Recommended