This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
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を利用した開発やシミュレーションに移行する際に必要となる変更とその影響を、ツールサプライヤーの観点から説明します。こうした変更は、ハードウェアから始まり、メッセージ内に含まれるデータフォーマット、そして各種通信レイヤーに至る多様なレベルで発生します。
CAN FDなどの新システム導入に際し、ソフトウェア開発ツールのサプライヤーが直面する課題は、顧客ベースで最初のCAN FDのECUが開発される時機を逸することなく、適切なツールを提供できるようにしておくことです。既存のテスト/シミュレーション環境にCAN FDを統合するには、ハードウェアからアプリケーションに至るさまざまなレベルで迅速に変更を行わなければなりません。また、通信ネットワークを記述するために、それに関連するデータベースも必要です。この状況で第一に考えるべきは、「CAN FDをモデル化するための最善策は何か?」ということです。有効データ長は最大64バイトですが、これを考慮するとPDUの抽出は必要でしょうか?PDU (Protocol Data Unit) はFlexRayで一般に使用されているだけでなく、AUTOSARシステム記述でもサポートされています。これらはCRCの詳細チェックなどの目的に使用するほか、Txトリガーとして利用することが可能です。基本的に、CAN FDをモデル化する際は、CANの分野で実績の
CAN FD対応のECUとネットワークの開発において、先進的な解析/テスト/シミュレーションツールによるサポートは貴重な助けとなるでしょう。その機能は、個々のネットワークノードの解析から、ネットワーク全体のシミュレーションに至るまで多岐にわたります。こうしたツールにより、開発者は信頼できるシミュレーションデータに基づいて今後のバス負荷を予測し、たとえば、ネットワークを複数に分割すべきかということにも適切な判断を下せるようになります。開発フェーズでは、このツールは残りのバスシミュレーションを実行するために用いられます。このシミュレーションは入手できないサブネットワークやそのコンポーネントを代行するもので、シミュレーションされたノードは、後から段階的に実際のECUに置き換えられます。このシミュレーションはゲートウェイの役目も果たし、それによって新しいCAN FDネットワークと従来のCANネットワークとを接続することができます。この場合、既存のCANのECUに変更を加える必要はありません。