HOME > ソフテックだより > 第315号(2018年10月3日発行) 技術レポート「SAE J1939プロトコルについて」

「ソフテックだより」では、ソフトウェア開発に関する情報や開発現場における社員の取り組みなどを定期的にお知らせしています。
さまざまなテーマを取り上げていますので、他のソフテックだよりも、ぜひご覧下さい。

ソフテックだより(発行日順)のページへ
ソフテックだより 技術レポート(技術分野別)のページへ
ソフテックだより 現場の声(シーン別)のページへ


ソフテックだより 第315号(2018年10月3日発行)
技術レポート

「SAE J1939プロトコルについて」

1. はじめに

弊社では、CAN (Controller Area Network)通信を行うアプリケーションの開発など、CAN通信関連の開発実績が多数あります。物理レイヤーにCANを使用した上位層の通信プロトコルも複数の使用経験がありますが、最近、通信規格「J1939プロトコル」を使用する機会があり、入社数年の私がその案件を担当することとなりました。
私はJ1939プロトコルについて全く無知でしたので、J1939プロトコルとはなにか、というところから理解する必要がありました。今回のソフテックだよりでは、その際に調査した内容をご紹介いたします。なお、CANについては過去のソフテックだよりで触れていますので、併せてご覧ください。

2. J1939プロトコルとは

J1939はSAE(Society of Automotive Engineers, アメリカの自動車関連の標準規格の開発などを行っている非営利団体)から提供されている通信プロトコルで、トラック、バスなどのディーゼルエンジンの制御、トラクター‐トレーラー間の制御などに使用されています。また、J1939の応用規格として、農業機械用のISO 11783や船舶用のNMEA2000などが存在します。

J1939の仕様書はSAEから購入することができます。下図に示す通り、仕様書はOSI参照モデルの各レイヤーに対応します。

OSI参照モデル
図1. OSI参照モデル

データリンク層、物理層、トランスポート層はCAN2.0B高速CANに準拠しています。
拡張CANID(29bit)を使用し、ボーレートは250kbit/s、500kbit/sに対応しています。
図1 OSI参照モデルのSAE J1939 /11で250kbit/s、SAE J1939 /14で500kbit/sの仕様が記載されています。

J1939は分散化ネットワークマネジメントを使用するマルチマスターシステムで、1ネットワークセグメントあたり最高254個のノードと30個のECU(Electronic Control Unit)をサポートします。

3. J1939プロトコルスタックソフトウェアと実装時の注意点

J1939プロトコルの仕様の概要についてご紹介いたします。また、実際の開発では1からではなく、市販のプロトコルスタックを購入して開発する場合が多いと思います。そのため、合わせて市販のJ1939プロトコルスタックソフトウェアを使用して実装する際の注意点についても簡単にご紹介いたします。

3.1 CAN ID

J1939でのCANIDは、以下のような構成となります。

Priority Extended
Data Page
Data Page PDU
Format
PDU
Specific
Source
Address
3bit 1bit 1bit 8bit 8bit 8bit

表1. CAN ID構成

J1939のCANIDは大まかに分けて、送信するデータがどのようなものかを示すパラメータグループの情報と、送信元のノードを示すSource Addressからなります。

3.1.1 パラメータグループ

パラメータグループは、類似したシグナルや関連性の高いシグナルのまとまりであり、仕様書J1939-71に定義されています。また、仕様書に定義されているもののほかに、ユーザー独自に定義し、使用することができます。パラメータグループは、固有のPGN(パラメータグループナンバー)によって区別されます。
パラメータグループの仕様は、使用するPGNとメッセージ中のデータ割り当て、送信周期をひとまとまりとして以下のように表記されます。

Torque demand message 1 – Base period is 5ms
Byte 0 1 2 3 4 5 6 7
PGN
0x11000
Torque demand Controlword Drive torque limit SEQ CS

表2. パラメータグループ表記

ブロードキャストで通信するパラメータグループは、PDU Formatに240以上を指定し、Extended Data PageからPDU Specificまでの18bitをPGNとして扱います。
1対1の通信をするパラメータグループは、PDU Formatが240未満を指定し、PDU Specificには通信相手のアドレスがセットされます(通信相手のアドレスに0xFF を指定した場合は、全ノードにあてたメッセージとなります)。PGNにはExtended Data PageからPDU Formatまでの10bitを使用し、PDU Specificの8bitは0にして表記します。
Extended Data Page, Data Pageはパラメータグループによって以下のように分類されます。

Extended Data Page Bit Data Page Bit 概要
0 0 SAE J1939 Page 0パラメータグループ
0 1 SAE J1939 Page 1パラメータグループ
1 0 SAE J1939 reserved
1 1 1ISO 15765−3で定義

表3. Data Page Bit

3.1.2 Source Address

Source Addressは同一ネットワーク内のノード固有のアドレスです。ノード間で送受信するメッセージでは、CAN ID内のSource Addressによって送信元ノードが明示されます。 Source Addressは以下のように分類されます。

名称 範囲 用途
Preferred address range 0〜127、248〜254 ノード用Source Address(選択アドレス)
Arbitrary address range 128〜247 ノード用Source Address(任意アドレス)
Source Addressがノード間で重複していた場合、優先度が低いノードはこの範囲から新しいアドレスを割り当てられます。
Zero address 254 アドレス割り当て失敗メッセージ送信
Global address 255 ブロードキャスト通信

表4. Source Address

Source Addressはノードごとにデフォルト値を設定します。また、ネットワーク内のノードごとに単一の値とするため、他のノードと通信を開始する前に後述のアドレスクレームを行う必要があります。

3.2 デバイスネーム

ノード同士を区別するため、各ノードには64bitからなるデバイスネームを付ける必要があります。デバイスネームは以下の10のフィールドから構成されます。

フィールド名 bit 位置 bit長 意味
Arbitrary Address Capable 0 1 アドレスクレーム失敗時の動作を示します。
Industry Group 1 3 業種を示します。
Vehicle System Instance 4 4 ノードの車両システム内でのインスタンスを示します。
Vehicle System 8 7 ノードの車両システムを示します。
Reserved

15

1 -
Function 16 8 ノードの機能を示します。
Function Instance 24 5 ノードの1機能内のインスタンスを示します。
ECU Instance 29 3 ノードの1機能内のECUのインスタンスを示します。
Manufacturer Code 32 11 SAEからメーカーごとに指定されるコードです。
Identity Instance 43 21 メーカー指定のノード用IDです。

表5. デバイスネームフィールド

上記のフィールドのうち、Arbitrary Address Capable、Vehicle System Instance、Function Instance、ECU Instance、Identity Instanceは使用者によって指定する必要があります。 その他のフィールドはSAE指定のコードを使用します。

3.3 アドレスクレーム

ノードがネットワークに加入する際、Source Addressを指定するために必ずアドレスクレームを実行します。
アドレスクレームは、PGNを0xEE00にし、Source Addressを自身に適用したいアドレスを入れたものをCAN IDとしたメッセージを送信することで行います。Priorityはデフォルトが6となっています。
具体例として、Source Addressを1にする場合のアドレスクレームCAN IDは下表のようになります。

Priority PGN 宛先アドレス Source Address 全体
6 0xEE00 0xFF 1 0x18EEFF01

表6. アドレスクレームCAN ID例

メッセージのデータ部には、デバイスネームが使用されます。

Source Addressが他ノードと重複している場合、デバイスネームによって優先度が決められ、優先度が高いノードに割り当てられます。重複によりアドレスクレームに失敗した場合、デバイスネームのArbitrary Address Capable bitが1ならば、Arbitrary address rangeから動的にノードのSource Addressを設定します。0ならば、アドレス割り当て失敗メッセージ送信を行います。市販のプロトコルスタックを使用する場合、ユーザー側でアドレスクレームの手順を意識し実装する必要はありません。

3.4 トランスポートプロトコル

ノード間の通信は、8byte以下のサイズならば単一のCANフレームで送信されます。 8byteより大きいデータを送信する場合、複数のCANフレームに分割して送信されます。 分割送信では、通信制御を行うTP.CM(0xEC00)とデータ送信を行うTP.DT(0xEB00)の2種類の専用PGNが使用されます。
TP.DTのデータ部には、1Byte目にシーケンス番号、2Byte目以降に送信データが格納されます。

3.4.1 1対1の送信

1対1の送信では、送信許可リクエストメッセージ(TP.RTS)、送信許可メッセージ(TP.CTS)、受信完了メッセージ(TP.EOM)を使用して送信ノードと受信ノードのハンドシェイクを行います。TP.RTS、TP.CTS、TP.EOMのPGNはTP.CMの0xEC00が使用されます。 以下に28Byteのデータを4つのTP.DTメッセージに分割して送信する例を示します。

1対1送信
図2. 1対1送信

送信ノードは受信ノード宛に、TP.RTSで送信データサイズを通知します。受信ノードはTP.CTSによって受信できるメッセージ数を通知し、送信ノードが受信できるメッセージの数だけTP.DTを送信します。送信データを全てTP.DTで送信し、受信ノードがTP.EOMを返すことで、1対1の分割送信が完了となります。

3.4.2 ブロードキャストの送信

ブロードキャスト送信では、ブロードキャストアナウンスメッセージ(TP.BAM)を送信した後、TP.DTメッセージでデータを分割送信します。
以下に21Byteのデータを3つのTP.DTメッセージに分割して送信する例を示します。

コーディング ― MainPage.xaml変更結果
図3. ブロードキャスト送信

送信ノードはTP.BAMで、送信するデータサイズを全ノード宛に通知します。その後、TP.DTを繰り返し送信し、全データを送信したところでブロードキャスト送信完了となります。

3.4.3 市販プロトコルスタックでの送信処理

市販のプロトコルスタックでは、ユーザー側で1対1送信かブロードキャスト送信か、また分割送信するかどうかを意識することなく送信処理を行えるようになっています。
以下にブロードキャストで分割送信を行う場合のサンプルソースコードをご紹介します。

static void send_sample(unsigned char uc_inst_num, unsigned char uc_send_data,
unsigned char uc_send_size)
{
  SAMP_MSG_PARAM s_send_msg;

  /* 送信メッセージヘッダ(CAN ID用データ)の作成 */
  s_send_msg.uc_addr = 0xFF; 	/* 宛先アドレス 		*/
  s_send_msg.uc_prio = 6;	/* 優先度		*/
  s_send_msg.ul_pgn = 65108; 	/* PGN	 		*/
  s_send_msg.ui_length = 12;	/* メッセージ長(byte) 	*/

  /* 送信データをメモリに割り当て */
  s_send_msg.puc_data    = SAMP_Alloc(s_send_msg.ui_length);
   if (s_send_msg.puc_data != NULL) 
  {
    /* 送信データをbyte配列に格納 */
    memcpy(s_send_msg.puc_data [0], uc_send_data, uc_send_size);

    /* メッセージの送信 */
    SAMP_Send(uc_inst_num , & s_send_msg); 
  }
}

※上記ソースコードは実際のソースコードとは異なります。

4. おわりに

今回は、SAE J1939プロトコルについて調査した内容をまとめさせていただきました。
現状では、J1939プロトコルを使用したソフト開発の経験は少ないですがが、市販のプロトコルスタックを活用することで、対応がずいぶん簡単になるのではないか、と考えております。J1939プロトコルに対応した機器も今後増えていくと思いますので、機会があればJ1939プロトコルを使用した開発の具体例などを、またご紹介できればと思います。

最後までお読みいただきありがとうございました。

(A.F.)


関連ページへのリンク

関連するソフテックだより

ページTOPへ