技術情報
産業用コンピューター
Kvaser - J1939およびDBC fileの概要
これは、J1939 DBC fileを理解し、操作するための入門ガイドです。
前提条件
- 16進法(Hexadecimal format)による数値表現の基礎を理解していること。
(16進数および2進数のナンバリングシステム(Kvaser英語サイト)) - シリアルデータ通信の概念を理解していること。
- Kvaser社のCAN Basics Webベースのトレーニング (Kvaser CANチュートリアル ※Coming Soon) のPart1, Part 2, Part 3 以上、または同等の知識があること。
概要
DBC fileは、CANフレーム内のデータに識別名、スケーリング、オフセット、定義情報を適用するために使用するASCIIベースの変換ファイルです。任意のCANIDについてDBC fileは、CANフレーム内のデータの一部またはすべてを識別できます。CANフレーム内のデータは、8の1バイト値、64の1ビット値、1の64ビット値、またはこれらの組み合わせに分割することができ、DBC fileは、これらの値のいずれか、またはすべてで表されるデータの識別、スケーリング、およびオフセットに使用できます。
はじめに
Controller Area Network(CAN)データの扱いに関し、ほとんどの場合、フォーマットと変換を理解することが必要です。CANデータを扱う場合、DBC fileのサブジェクトが導入されるまでにそれほど時間はかかりません。これは、データの識別と変換を処理する最も一般的な方法だからです。具体的には、CANメッセージの識別とCANフレーム内で送信される生のCANデータの意味ある値および意味ある情報への変換について言及しています。
DBC fileタイプは、1990年代にVector Informatik GmbHにより開発されたCANネットワークで記述された情報を保存するための標準的な手段です。Vector database files(.dbc)は、主に自動車業界で使用され、その後、CANの記述を交換するための業界標準(de facto standard)となっています。他のbusシステムでは、FlexRayのためのFIBEX database files (.xml)やLINのためのLDF(.ldf)など同様の規格が存在します。
SAE J1939規格はDBC fileを完全に理解した上で書かれ維持されていますが、その用語や詳細は、規格で殆ど言及されていません。実際、最近、SAE J1939規格ドキュメントの多くをスキャンした結果、DBC fileの文脈では、"DBC"または"database"という用語は、どのドキュメントにも表示されていませんでした。
DBCは'database'の略で、エンジニアがこの2つの名前を使い分けているのを耳にします。databaseという言葉は、他に色々なところで、色々な文脈で使われていますがCANデータに関連して使われる場合は、DBC fileのことを指しています。
J1939 DBC file
DBC fileファイルに限定して考えた場合、SAE J1939規格委員会(正式名称:Truck Bus Control and Communications Network Committee)は、いかなる種類のDBCファイルも維持・配布していないことを理解することが重要です。規格委員会は、DBC fileで表現される多くの識別子、名前、番号、およびフォーマットを割り当てていますが、ファイル自体はSAEの製品ではありません。SAEは、J1939 DBC DBC fileを作成するために必要な技術情報を伝えるために使用するWindows Excelファイルを管理および販売しています。このExcelファイルは、J1939DA(Digital Annex)と呼ばれ、SAEのサイト(英語)から購入することができます。
Digital Annexを入手したら、その中の情報のすべてまたは一部を含むJ1939 DBC fileを作成できます。製品がSAE J1939規格の中のいくつかのメッセージを理解するだけであれば、DBC fileは、製品が理解する必要のあるメッセージを定義するだけでよく、その他のメッセージはDBC fileで定義する必要はありません。
DBC fileを読むことができるPCのためにWindowsアプリケーションは、KvaserのCanKing、Accurate TechnologiesのVisionおよびCANLab、TK EngineeringのCANtrace、MathworksのMATLAB Vehicle Network Toolbox、Pi InnovoのPiSnoop、Warwick ControlsのX-Analyser、VectorのCAN db++など、数多くあります。また、必要に応じてDBC fileをWindowsのWindows Notepadで編集することもできますが、このファイルは理解しづらく、特殊な文字を使って異なることを行うため、この方法は難しくなります。DBC fileを閲覧および編集するための1つの簡単な方法として無料のKvaser Database Editor 3があり、Kvaserサイト Downloads(英語)からダウンロードできます:
異なる機能を持つDBC file editorを提供するサプライヤは他にも多数ありますがKvaserパートナの中には、Kvaser Database Editorを自社のツールに組み込んでいるところもあります。
ほとんどのPCベースのソフトウェアアプリケーションでは、複数のDBC fileを同時に使用することができます。これは、特定のCAN busにJ1939メッセージとプロプリエタリ(独自)のメッセージや他のプロトコル、さらには校正データなどJ1939で定義されていない他の情報が含まれていることがあるためです。そのアプリケーション内の異なるデータを定義するために1つのCAN bus監視アプリケーションに関連付けられた2つ以上のDBC fileがあることは一般的です。また、関連するDBC fileのいずれによっても定義されていない複雑なCANネットワーク上のメッセージを見るのも一般的であり、この場合、メッセージは、通常、アプリケーションによって生CANデータとして表示されます。
法的問題
SAE J1939DまたはDigital Annexは、SAEによって知的財産であると考えられているため必要に応じてSAE特許および/または著作権によって保護されています。SAE IPステートメントの最初の行は次のとおりです:SAEの知的財産は、その最も貴重な資産です。従って、協会は、その知的財産権を維持し、保護するためにかなりのリソースを費やしています。
J1939 DBC fileは、SAE J1939DA内の情報のデジタル表現であるためSAEは、J1939 DBC fileを知的財産とみなします。弁護士ではないので、SAE知的財産と見なされる可能性のあるものを再販する前に、弁護士とSAEの利用規約(英語)の確認をすることをお勧めします。
J1939プロトコルスタックの購入について
システム開発用のJ1939プロトコルスタックは、多くのKvaserテクニカルアソシエイトが販売しています。詳細については、お問い合わせください。
- emotas GmbH (Germany)
http://www.emotas.de/en/produkte/sae-j1939-stack - LogiCAN (Israel)
https://www.logi-can.com/ - Warwick Control Technologies (UK)
https://www.warwickcontrol.com/protocol-stacks/
CAN frame内のデータの理解
DBC file内の情報を本来の目的通りに使用するためには、データをCAN frameの識別子から分離する必要があります。本記事は、DBC fileの理解を目的としていますので、CAN frameの詳細については触れませんが、データから識別子を分離する方法だけはご紹介します。ここでは、CANKing内で表現される29ビットの識別子と8バイトのデータを持つ典型的なCAN frameの例を示します。
このCAN frameの各セクションは、情報の異なるブロックを区別するために強調表示されており、これらの各ブロックにはaからgまでの小文字のラベルが付けられています。
- a - これは単にデータが受信されたデバイスのチャンネルを表します。0は、チャンネル1を表します。
- b - メッセージの識別子。識別子には、メッセージのプライオリティ、Parameter Group Number(PGN)、Source Address(SA)が含まれているので、より理解しやすくなっています。
- c - Xは、これが拡張識別子メッセージまたは29ビットの識別子であることを示しています。
- d - データ長コード(DLC)が8であることは、このメッセージが8バイトのデータを含んでいることを意味しています。
- e - これは私たちが求めているものであり8バイトのデータです。
- f - これは秒単位のタイムスタンプであり、アプリケーションによって受信された各CAN frameに追加されます。
- g - Rは、このフレームがCANKingによって受信されたことを単に示しています。
CAN frameのデータ部分を分離したことで、データがどのように表現されているかを理解することができます。そこで注目したいのがDBC fileです。DBC fileは、アプリケーションがデータを理解し、データを分解し、スケールとオフセットを適用し、データにラベルを付け、解釈するために必要な情報を提供します。ここでの説明は、データを受信する側の観点から提示されています。CAN frameを受信すると、これらのすべてを行います。もし、これをCAN frameの作成や送信に適用するとしたら、発想を逆転させ、運用の順序を逆にさせます。ここでは、CAN frameの受信に関するDBC fileについて説明します。これを理解すれば送信側を理解することも難しくありません。
DBC fileの使用例
特定の監視ソフトウェアでCAN traceを見ていて、そのトレース内のメッセージが関連するDBC fileで定義されていない場合、そのメッセージは、生のCAN frameとして表示され、次のようになります:
これは、KvaserのCANモニタリングアプリケーションCANKingでキャプチャしたもので、Kvaserのどのインターフェースでも動作する無料のCANモニタリングアプリケーションです。CANKingは、KvaserサイトKvaser Downloads(英語)からダウンロードできます。
CANKingでは、Formatterと呼ばれるものを使用してデータをフォーマットし分かりやすく表示をします。CANKingでは、異なるFormatterを選択することができます。これは、Select Formatter windowを開くことで行います。上のデータは、CANKingのStandard Text Formatオプションを使用してフォーマットされています。この記事は、DBC fileに関するものなのでCANKingとそのFormatterについてこれ以上詳しく説明するつもりはありませんが、この記事の例で使用するデータの表示にCANKingを使用しているので、フォーマッティングオプションと異なるフォーマットについて少し触れておくことが重要です。
CANKingは、このデータをより意味のある読みやすいものにするためにDBC fileを読み込んで使用することができます。このテストのために適切なDBC fileをCANKingにロードするプロセスを経ると、このCAN frameの識別子が認識され、順序、順番内のデータに適切な翻訳と識別子が適用されます。これでディスプレイは、次のようになります:
0 18FE6900 X 8 9C 27 DC 29 FF FF F3 23 230.871160 R
CAN 1 65129 0 all 6 J1939.ET3 230.871160 R
9C27DC29 FFFFF323
-> EngChargeAirCooler1Outlet 14.5938 deg C
-> EngIntkVlvActuationSystem 1774.9688 deg C
-> EngIntakeManifold1AirTemp 43.8750 deg C
-> EngCoolantTemp 61.8750 deg C
この場合,メッセージは、ET3として識別され,このメッセージでの信号の1つは、EngCoolantTempとして識別されます。これらの識別情報はすべてDBC file内に含まれており、この場合、DBC fileの名前はJ1939.dbcです。CANKingアプリケーションは、CANメッセージ18FE6900のヘッダの一部を使用して、DBC file内の情報を参照し、メッセージをET3として識別します。メッセージが特定されると、CANKingは、データに入り込み、読者にとって意味のあるデータのフォーマットとラベル付けの方法を理解することができます。
この例では、データ内の1つの信号(EngCoolantTemp)信号だけに集中します。ここでは、無料のKvaserアプリケーション、Kvaser Database Editor 3から抜粋します。
このデータからわかることは、信号EngCoolantTempは、Intel formatのunsigned integerで、ビットポジション16で始まり、16ビット長であるということです。また、オフセットは、-273、信号のスケーリングファクタは、0.03125であることがわかります。
これで、DBC fileの情報と、信号EngCoolantTempのデータを使って、CANKingが行うことを手動で実行することができます。まず、信号を分離します。ここでは、メッセージで送信された8バイトのデータで信号EngCoolantTempは、赤枠で囲んでいます:
信号EngCoolantTempがメッセージ内のどこにあるかをどのようにして知ることができますか? DBC fileによると信号は、ビットポジション16から始まり、16ビットの長さであると伝えています。データを左から右に読むと、最初の8ビットポジション(ビット0~7)に9C、メッセージの2番目のバイト(ビット8~15)に27、そしてビットポジション16~31にDC29があります。そこでビット16から31は、知りたいEngCoolantTempの16ビット値であることを表しています。
オフセットとスケーリングファクタを適用する前に、byte orderを気にしなければなりません。ここでByteorder Intelが登場します。Intelのbyte orderフォーマットは、Little-end-inまたはLeast Significant Byte (LSB) firstというものです。least significant byte(最下位バイト)が先に送信される場合、信号の2バイトを逆にしなければならず、信号は29DCになります。これは、オフセットとスケーリングが適用される前に信号EngCoolantTempに対して送信された16進値です。
次に、この値を10進法に変換する必要がありますが、これは手計算するか、プログラマーモードに設定したコンピュータの電卓で行います。
29DC(ベース16)=10,716
29DC(base16)=10,716(この変換が自然にできない場合は、ベースの異なるナンバリングシステムや、HEXから10進法への変換に戻って復習してください)。
ここで、スケールとオフセットを適用する準備ができました。スケールとオフセットの両方は、どちらも10進数で表示されているので、EngCoolantTempの10進数の値である10,716に適用します:
まず、スケールを適用します:
10,716 x 0.03125 = 334.875
次に、オフセットを適用すると、次のようになります:
334.875 - 273 = 61.875
この信号の単位はdec Cであるため、上記のCANKingからの抜粋で示されているように、答えは61.875 deg Cとなります。
ご覧の通り、CANKingが解釈したEngCoolantTempの値を返ってみると、ここで計算した値と全く同じです。ここの手作業で行ったことは、DBC fileを使用して人が読めるフォーマットでデータを表示するソフトウェアアプリケーションで行われるのと全く同じ計算です。CANバスインターフェースを介して受信した生データをバスから受信したままの状態で、適切なDBC file内の定義と情報を適用し、生データをオフセットおよびスケーリングして人が読める値にしました。DBC fileの情報がなければ、CANデータは意味のないものになってしまいます。従って、DBC fileは、CAN busで通信される識別情報とデータに関する重要な情報を伝えるための最も一般的な方法であると結論づけられています。