技術情報

概要

J1939は SAEが定めた規格です (こちら にJ1939 Standards Overviewがあります)。トラックやバスなどの大型車両、移動式油圧機器などで使用されています。J1939は、多くの点で、旧規格であるJ1708やJ1587と似ていますが、J1939はCANをベースに作られています。

物理層(J1939/11)はbusの電気的インターフェースを記述しています。データリンク層(J1939/21)は、メッセージの構成、busへのアクセス、伝送エラーの検出などのルールを記述しています。アプリケーション層(J1939/71およびJ1939/73)は、ネットワークを介して送信される各メッセージに含まれる特定のデータを定義しています。

クイックファクト

• CAN上に構築された上位層プロトコル
• トラックやバスなどの大型車両で使用
• スピードは、ほぼ常に250 kbit/s または 500 kbit/s
• J1939 DBC fileの具体的な説明については、こちら をご覧ください。

関連製品

00915-8 Kvaser Leaf Light HS v2 J1939-13 Type II

シングルチャネル USB－CAN PCインターフェース, CANアクセス用 J1939-13 Type IIコネクタ(グリーン)

製品情報 (00915-8 Kvaser Leaf Light HS v2 J1939-13 Type II)

メッセージのフォーマットと使い方 (J1939/21)

J1939規格で定義されている殆どのメッセージは、ブロードキャストを目的としています。これは、データが特定の宛先なしにネットワーク上で送信されることを意味します。これにより、どのデバイスも追加の要求メッセージを必要とせずにデータを使用することができます。また、将来のソフトウェアの改訂時に、新しいデバイス(アドレスの割り当て)に容易に対応することができます。特定のデバイスにメッセージを送る必要がある場合は、message identifier(メッセージ識別子)内に特定の宛先アドレスを含めることができます。例えば、ブレーキコントローラから特定のトルク値を要求する代わりに、エンジンから特定のトルク値を要求する場合です。

J1939では、図1のCAN 2.0Bプロトコルにより定義された29ビットの識別子を使用します。識別子は、ブロードキャストを目的としたメッセージ("PDU 2")と比較して、宛先アドレス("PDU 1")のメッセージでは、わずかに異なる使い方をします。

PDUは、Protocol Data Unit(＝メッセージフォーマット)の略です。

SOF、SRR、IDEの各ビットはCAN規格で定義されており、ここでは無視します。RTRビット(remote request bit)は、J1939では常に0に設定されています。

J1939で使用される29ビットの識別子は、以下の構造になっています。

Table 1：29ビット識別子の構造

識別子の最初の3ビットは、調停プロセス中にメッセージの優先順位を制御するために使用されます。値0は最も高い優先順位です。通常、高い優先順位値は、high-speed制御メッセージ(例えば、トランスミッションからエンジンへのトルク制御メッセージ)に与えられます。車両の道路スピードなど、時間的に重要ではないデータを含むメッセージには、優先順位の低い値が割り当てられます。

識別子の次のビットは、将来の使用のために予約されたもので、送信されたメッセージの場合は0に設定する必要があります。

識別子の次のビットは、data page selectorです。このビットは、識別子で表すことができるParameter Groupsの数を増やします。

PDU format(PF)は、メッセージを宛先アドレスで送信できるかどうか、またはメッセージが常にブロードキャストメッセージとして送信されるかどうかを判別します。

PDU specific(PS)フィールドの解釈は、PF値に基づいて変更されます。

• PFが0～239間の場合、メッセージはアドレス指定可能 (PDU1)であり、PSフィールドには宛先アドレスが入ります。
• PFが240～255間の場合、メッセージはブロードキャスト(PDU2)のみで、PSフィールドにはGroup Extensionが含まれます。

Group Extensionは、識別子で表すことができるブロードキャストパラメータグループの数を拡張します。

Parameter Group Number (PGN)という用語は、予約ビット、DP、PF、およびPSフィールドをシングルの18ビット値に結合した値を指すために使用されます。

例: ID 0xCF004EEは、Table 2の以下のフィールドに分けることができます。

Table 2：PGNサンプル

• PGN = R、DP、PF、およびPSフィールド (この場合、0x0F004)。
• PF = 0xF0 = 240、つまりこれは、PDU2(ブロードキャスト)メッセージ。
• PS = 0x04、すなわちGroup Extension = 4

識別子の最後の8ビットにはメッセージを送信するデバイスのアドレスが含まれています。アドレスは、ネットワーク上の特定のデバイスに一意にアクセスする方法を提供するために割り当てられるラベルまたは "handle" です。特定のネットワークでは、すべてのアドレスが一意である必要があります(254使用可能)。これは、2つの異なるデバイス(ECU)が同じアドレスを使用できません。

アドレス および Name (J1939/81)

Nameは、64ビット(8バイト)長のラベルで、すべてのECUに一意のIDを与えます。Nameは、10フィールドで構成され、Table 3に示す構造になっています。

Table 3：Nameの構造

• Arbitrary address bit
• Industry group, 長さ3ビット
• Vehicle system instance, 長さ4ビット
• Vehicle system, 長さ7ビット
• Reserved bit
• Function, 長さ8ビット
• Function instance, 長さ5ビット
• ECU instance, 長さ3ビット
• Manufacturer code, 長さ11ビット
• Identity number, 長さ21ビット

Nameの主な目的は、ECUを記述することです。下位の機能フィールド値(0～127)は、"standard"機能またはデバイスに事前に割り当てられています。値128～254は、Industry GroupおよびVehicle System値に依存します。この依存関係により、異なる車両で同じ機能を配置することが可能になります。また、このシステムにより、トレーラーや農業機械などのデバイスが利用可能なアドレスの検索を制限し、アドレスを動的に要求する時間と困難さを最小限に抑えることができます。アドレスを要求するとき、名前はどのECUがより高い優先度を持っているかを決定するために使用され、従って要求されたアドレスを取得します。

ネットワーク上の各デバイスには、少なくとも1つのNameと1つのアドレスが関連付けられます。しかしながら、シングルのECUの中に、複数のデバイス名と複数のアドレスが共存している場合があります。例えば、エンジンとエンジンブレーキ(retarder)がシングルの物理的なバスコネクションを使った共通のデバイスに存在するような場合を意味します。デバイスアドレスは、メッセージの特定の通信送信元または宛先を定義します。Nameは、ネットワーク上に同じタイプのデバイスが複数存在する場合、機能を識別し、その機能の固有のインスタンス番号を追加します。アドレス制限により、同じタイプの254の異なるデバイスのみがネットワーク上に共存できます。アドレス255は、ブロードキャスト用のグローバルアドレスとして予約されており、アドレス254は、まだアドレスを要求していないか、アドレスを要求できなかったデバイスによって使用される"null address"として予約されています。

アドレス要求(Address Claim)

一般的に、殆どのアドレスは事前に割り当てられ、電源投入時にすぐに使用されます。J1939では、まだ定義されていない将来のデバイスや機能に対応するためにアドレスを動的に割り当てる手順が規定されています。各デバイスは、関連付けられているアドレスをアナウンスする必要があります。これは、識別(アドレス要求)機能です。2つのオプションを使用できます：

1. Address Claimメッセージを送信して、アドレスを要求します。

デバイスがAddress Claimメッセージを送信してアドレスを要求すると、すべてのデバイスは、この新しく要求されたアドレスをネットワーク上のデバイスの独自のテーブルと比較します。アドレスが、より高い優先順位を持つデバイスによって既に要求されている場合、そのデバイスは、アドレスが既に使用中であることを示すAddress Claimメッセージを送信します。Address Claimメッセージのデータとして送信されるNameは、どのデバイスの優先順位が高いかを決定します。

2. Address Claimの要求を送信

デバイスがAddress Claimを送信すると、すべてのデバイスがAddress Claimメッセージを送信して応答します。これにより、移行デバイス(ツール、トレーラーなど)または電源投入が遅れたデバイスが現在のアドレステーブルを取得できるため使用可能なアドレスを選択して要求できます。図2を参照してください。

煩雑さのないAddress Claim

動的アドレス割り当てのサポートはオプションであり、アドレスのコンフリクトが発生すると予想されるデバイスのみがこの機能をサポートする必要があります。動的アドレス割り当てをサポートする必要性を排除し、この"identity process"(IDプロセス)を高速化するために、殆どのECUは優先アドレスに関連付けられています。これらの優先アドレスについては、ドキュメントJ1939/71に記載されています。優先アドレスが別のECUで既に使用されている場合、デバイスがセルフコンフィギュレーションをサポートしている場合、デバイスは別のアドレスを要求することができます。

メッセージの送信(J1939/21およびJ1939/7x)

特定のデータ項目を送信するには、送信するデータを記述したオーバーヘッドのあるメッセージを作成する必要があります。関連するデータ項目は、通常、オーバーヘッドを減らすためにメッセージ内にまとめられます。J1939/71は、メッセージで送信されるパラメータを記述するいくつかの標準PGNを定義しています。また、J1939/71には、メッセージの優先順位および伝送レートに関する情報も含まれています。デバイスに特定のパラメータで使用可能なデータがない場合、このパラメータを含むはずのバイトが "not available" (0xFF)に設定されるため、受信者はデータが欠落していることを認識できます。8バイト以上のデータを必要とするメッセージは、マルチパケットメッセージとして送信することができます。マルチパケットメッセージは、J1939/21で定義されているTransport Protocol Functionsを使って送信されます。しかしながら、マルチパケットメッセージを送信するには2つの方法があります：

• Broadcast Announce Message (TP_BAM)
• Connection Management (TP_CM)

TP_BAMメッセージ

TP_BAMメッセージは、global destination address(グローバルな宛先アドレス)を使用しているため、ネットワーク上のすべてのデバイスがこれらのメッセージを受信することを意味します。送信は、TP_BAMを表すコントロールバイトを持つConnection Management(CM)メッセージ(PGN=0x00EC00)で開始されます。メッセージデータは、PGN=0x00EB00のData Transfer (DT)メッセージに続きます。

TP_CMメッセージ

TP_CMメッセージは、2つのデバイス間のポイント・ツー・ポイントで送信されます。送信は、RTS(Request To Send)を表すコントロールバイトを持つCMメッセージで始まります。受信側デバイスは、Clear To Send(CTS)を示すコントロールバイトを含むCMメッセージで応答します。送信側のデバイスは、その後でCTSで示されたデータの一部をDTメッセージで送信します。このCTSとDTメッセージのハンドシェイクは、メッセージ全体が送信されるまで続きます。コネクションは、メッセージの完了時に、受信者がEnd Of Message確認応答(EOM)を示すコントロールバイトを含むCMメッセージを送信することによって終了します。このプロセスが機能するために、CMメッセージにはコントロールバイトが何であるかに基づいた追加データが含まれていることに注意してください。RTSには、バイト数、パケット数、データが転送されるPGNが含まれています。CTSには、受信者が次に期待するパケット数および開始するパケット番号が含まれています。

メッセージの受信 (J1939/21およびJ1939/7x)

選択したメッセージをネットワークからキャプチャするために利用できる様々な手法(およびチップ)があります。しかしながら、受信したメッセージに関しては、いくつかの一般的な観察を行うことができます：

• メッセージが宛先特定の要求またはコマンドである場合、デバイスは、宛先アドレスがデバイスによって要求されたアドレスと一致するかどうかを判断する必要があります。一致した場合、受信側デバイスは、メッセージを処理し、何らかのacknowledgmentを行わなければなりません。
• メッセージがグローバルな要求である場合、すべてのデバイスは、例え、originator(発信者)であっても、その要求を処理し、データが利用可能であれば応答しなければなりません。
• メッセージがブロードキャストの場合、各デバイスは、コンテンツが関連性のあるものかどうかを判断しなければなりません。

ECU設計(J1939/1x、J1939/21、およびJ1939/7x)

製品に含まれるelectronic control unit(ECU)のパフォーマンス要件は、マニュファクチュアラーごとに異なりますが、J1939をサポートするために必要なリソースに関していくつかの観察を行う必要があります。J1939の現在のデータレートは250 Kbpsです。8データバイトを含む一般的なメッセージは128ビット長(bit stuffingに使用されるビットを除く)で、時間は約500マイクロ秒です。最も短いメッセージは64ビット長です。これは、新しいメッセージが250マイクロ秒ごとに送信できることを意味します。すべてのメッセージが関連するわけではなく、バスの負荷が50％以上になるとは限りませんが、受信側のプロセッサは、短い時間のバーストのためにメッセージを連続的に処理(またはバッファリング)できる必要があります。そのためには、メモリ転送のためのプロセッサ時間だけでなく、RAMのスペースも必要になります。

配線トポロジー - 物理層 (J1939/1x)

J1939ネットワークは、車両の通信を行うことを目的としてシールドツイストペア線を使い各ECUの接続を行います。ECUと"bus"間にはショートスタブが認められています。これにより、メインバスを各ECUに直接接続する必要がなくなり、メインバスの配線をシンプルにすることができます。電気信号の反射を最小限に抑えるには、250Kbpsのデータレートでリニアバスが必要です。また、バスの両端に終端抵抗を接続することで反射を抑えることができます。

J1939ネットワークは、実際には複数のセグメントで構成され、それらの間にブリッジと呼ばれるインラインデバイスが存在する場合があります。これらのセグメントは、お互いに直接互換性がある必要はありません。例えば、セグメントが異なるデータレートでの動作や、異なる物理媒体を使用していてもかまいません。ブリッジの主な機能は、セグメント間を電気的に絶縁するためです。トラクターとトレーラーの間のワイヤが切断された場合でも、トラクター上のJ1939セグメントは機能し続けます。また、ブリッジは、どのメッセージを保存、あるセグメントから別のセグメントに転送する必要があるかを選択的にフィルタリングすることもできます。

J1939メッセージの解釈方法の例

この例は、J1939メッセージの解釈方法の原則を提供することを目的としています。
以下のような内容のJ1939メッセージを見てみましょう。

CAN-IDは、どのような情報を提供するのですか？

最初の2バイト＝0x0C＝00001100(binary format)です。識別子は29ビットで構成されているため、最初の3ビットは使用されません。続く3ビットは、メッセージのプライオリティを表し、この場合は3となります。その後、予約ビットと、完全なPGNを決定するために使用されるデータページが続きます。

CAN-IDの最後のバイトは、ソースアドレス(送信デバイスのアドレス)で、この場合は1です。

PGN=0x0F004は、J1939/71ドキュメントによるとElectric Engine Controller #1(EEC1)に相当します。また、このドキュメントでは、パラメータとそのデータバイト内のポジションも記述されています。この例では、データフィールドは以下のバイトで構成されています：

この例のデータバイト1、2、6、7、および8は使用できないため、0xFFに設定されます。0xFFという値の生のパラメータ値(シングルバイト)はありません。

データバイト3は、実際のエンジンパーセントトルクのパラメータです。生の値0x82は10進数で130です。J1939/71のドキュメントによると、スケーリングは1ビットあたり1%で、オフセットは-125です。従って、このパラメータの実際の値は5％となります。

データバイト4と5は、エンジンスピードのパラメータを形成します。最初のバイト(4)は最下位です(Intelのバイト順)。生の値0x1ADF＝6879の10進数です。スケーリングは1ビットあたり0.125rpm、オフセットは0です。従って、このパラメータの実際の値は859.875rpmをわずかに下回ります。