SAE J1939

開発と生産に必要なのはこれだけ


HMS の製品とサービスで実現できること:

  • すぐに使えるモジュールまたはプロトコルスタックを使用して、SAE J1939 プロトコルを柔軟かつ簡単にお客様のデバイスに実装
  • SAE J1939 対応デバイスと他の産業用ネットワークの接続
  • PC を SAE J1939 システムに接続し、PC ベースの制御、設定、解析を実現
  • お使いのシステムを解析、メンテナンス

SAE J1939 テクノロジー概要
SAE J1939 Products and Services
プロトコルソフトウェア
 

デバイスへの SAE J1939 の実装

クロスプラットフォーム SAE J1939 スタックを使用すると、J1939 デバイスを素早く容易に開発することができます。SAE J1939 仕様で定義されているすべての通信メカニズムを使用することができ、お客様はアプリケーションの開発に集中することができます。

  • さまざまなマイクロコントローラーシステムやコンパイラーに対応

emotas SAE J1939 Stack

 
PC Interfaces
 

PC と SAE J1939 システムの接続

Ixxat PC CAN インターフェースは、PC ベースのアプリケーションと SAE J1939 ベースのシステムの簡単な接続が可能です。

  • 様々なカード形状と PC インターフェース規格に対応
  • お客様固有の PC ベース SAE J1939 アプリケーション向け Windows API 

SAE J1939 対応の PC CAN インターフェース
Windows 向け SAE J1939 API

 
CAN Tools
 

解析と設定

SAE J1939 製品の開発、システム設定、トラブルシューティングに最適なツール製品を豊富に取り揃えています。

  • canAnalyser – SAE J1939 のメッセージやシグナルを容易に解析、送信、ログ
  • emotas J1939 DeviceDesigner - emotas J1939 stack に対応する J1939 プロジェクトのエディターとコードジェネレーター
  • CANopen トラブルシューティング – パワフルな小型ツール及び PC ベースのツール

CANopen 拡張 canAnalyser
emotas J1939 DeviceDesigner
SAE J1939 診断とトラブルシューティング


SAE J1939 対応の総合的なツールチェーン

HMS は、SAE J1939 アプリケーション向けの総合的かつコスト効率の高いツールチェーンを提供しています。プロトコルソフトウェア、解析や設定のためのツール、そして Windows API ベースのテスト用デバイスまで幅広く取り揃えています。
 
  • SAE J1939 Designer で、ツールチェーン全体のすべての関連パラメーターを 1 ヶ所で定義
  • 一貫性のないデータセットによって発生するエラーを回避し、開発スピードを大幅に加速
  • 開発リスクの低減、開発コストの削減、市場投入までの時間短縮が可能

SAE J1939 – 概要

標準化されている商用車分野では、個々の電子制御ユニット(ECU)と動力伝達装置のコンポーネント間の通信に使用されるシリアルプロトコルは少し前から共通です。共通のシリアルプロトコルを使用することは、次のようなメリットにつながります。

  • コンポーネントのメーカーに求められるのは 1 プロトコルの導入のみで、このことは生産台数が少ない商用車のケースでは大変重要
  • 商用車メーカーは、さまざまなサプライヤーから提供されるコンポーネントに頼ることができる
  • コンポーネント間の相互運用性が保証されている、つまり、複数メーカーのコンポーネントが調整なしで連動することができる

 

SAE(international Society of Automotive Engineers)が定義したプロトコル SAE 1939 は、SAE 規格 J1587 / J1708 の後継として、ISO 11898 準拠の CAN High Speed を使用して物理レイヤー上で動作します。

SAE J1939 は、オンロードとオフロードを問わずトラックやトレーラー、建機車両やクレーンなど、幅広い大型商用車で使用されています。農業機械や林業機械の分野では ISO 11784 の後に ISOBUS が適用され、海洋環境ではプロトコル NMEA2000 が使用され、軍事分野では MilCAN が適していますが、これらのプロトコルはすべて J1939 をベースとしています。

既存の J1708/J1587 プロトコルとの互換性が求められたせいで、J1939 には CAN メッセージ ID の 11 ビットから 29 ビットまでの拡張、CAN モジュールの開発、そしてそれぞれのプロトコルの導入が必要とされました。

J1939 を用いると、測定値と制御データの両方の伝送、ならびにコンポーネントの設定が可能です。さらに、各コンポーネントの診断データの読み取りや削除、それぞれの制御のキャリブレーションを実行する機能があります。

J1939 プロトコルでは、伝送のモード、メッセージ構造やそれらの分割、フローの制御などが指定されるだけでなく、メッセージの内容自体も細かく定義されます。 

 

 

ISO/OSI 参照モデルにおける SAE J1939

SAE J1939 は OSI 参照モデルに従って複数のドキュメントに分割されています。そのドキュメント番号は参照モデルの対応するレイヤーを指しています。あらゆるフィールドバスプロトコルに事実上類似している SAE J1939 では、レイヤー 5 と 6 は必要ではないため、指定もされません。

 

J1939-Technology-ISO-OSI-Layers

図:ISO/OSI 参照モデルにおける SAE J1939

 

物理レイヤー

CAN バスをベースとする SAE J1939 プロトコルは、CAN バスを物理レイヤー(Controller Area Network、ISO 11998-1 および ISO 11998-2)として使用しています。その仕様は次のとおりです。

  • SAE J1939/11:シールドツイストペアケーブルおよびアース端子による ISO/DIS 11898 準拠の CAN High Speed バス接続を定義。データ転送速度は 250kbit/s、最大ノード数は 30、最大ケーブル長は 40 メートル。
  • SAE J1939/12:4 線式でアクティブなバス終端を伴う仕様を説明。シールドの必要性をなくし、安価なケーブルの使用が可能。
  • SAE J1939/14:データ転送速度が 250kbit/s から 500 kbit/s という 2 倍の仕様。
  • SAE J1939/15:シールドされていないツイストペアケーブルの使用が可能。ただし、1 つのネットワークで 10 以上の ECU を接続できない。 

 

データリンクレイヤー

SAE J1939/21 は、CAN 2.0B の仕様に基づく CAN によるデータ通信を説明しています。「Extended Format」はこの通信だけに使用され、「Standard Format」はベンダー固有のアプリケーションだけに使用されます。
この仕様では、さまざまなベンダー固有メッセージの ID の競合をなくすために 11 ビット ID をどのように使用する必要があるかを指定しています。29 ビット ID の割り当てと使用のほかに、この仕様では原則的にメッセージリクエストモード、確認済み送信、大きなデータブロックのフラグメント送信のためのさまざまなネットワークサービスについて記述されています。

 

ネットワークレイヤー

SAE J1939/31 は、原則として 2 つのネットワークセグメント間でメッセージを伝送するブリッジ機能を記述しています。ブリッジに備わるフィルター機能により、トラクターとそのトレ-ラー間など、個別のセグメントにおけるメッセージトラフィックを減らすことが主な働きです。

 

アプリケーションレイヤー

アプリケーションレイヤーでは、ドキュメント SAE J1939/71 で実際のデータ(値範囲、分解能、物理装置、送信タイプを伴うパラメーターまたはネットワーク変数)について記述しています。各メッセージはそれぞれ、ある番号(パラメーターグループ番号:PGN)で一意的に識別されます。

 

ネットワーク管理

J1939 のネットワーク管理は分散されているため、各制御ユニットに最小限の機能が備わっている必要があります。ネットワーク管理機能はドキュメント SAE J1939/81 に記述されています。ネットワーク管理はハードウェア(レイヤー 1)に到達する別のユニットとして認識できるため、図の右側にある独立したファンクションブロックとして表示されます。

 

 

デバイスネーム、メッセージ構造、アドレスクレーム(J1939/81)

 

デバイスアドレス

 

電子制御ユニット(ECU)のソフトウェアは、Controller Application(CA)です。ECU には 1 つまたは複数の CA が組み込まれていることがあります。それぞれの CA には固有のアドレスがあり、デバイスネームが関連付けられています。CA によって送信された各メッセージには、このソースアドレスが含まれます。

 

J1939-Technology-device-address

J1939 のアドレススペースには、使用できる 256 のデバイスアドレスが存在します。

  • 0..127:Preferred address と定義された機能を持つ CA 向けに使用 
  • 128..247:すべての CA で使用可能
  • 248..253:Preferred address と定義された機能を持つ CA 向けに使用 
  • 254:空値
  • 255:グローバル

エンジン、トランスミッションなどの多くの CA には Preferred address があります。 

 

デバイスネーム

J1939 は、それぞれ 64bit(8 バイト)長のラベルで表され、デバイスとその機能の識別に使用するデバイスネームを定義します。デバイスネームは複数の要素に分割され、そのうちのいくつかは相互依存しています。独立したフィールドには「Industry Group」や「Manufacturer Code」があります。

 

J1939-Technology-device-name

図:デバイスネームの構造

  • J1939 は従来型の商用車だけでなく農業工学や海洋部門でも使用されているため、ネットワークで必要とされる機能は Industry Group によって決まります。
  • Manufacturer Code は、SAE に申請する必要があり、割り当ても SAE によって行われます。この Manufacturer Code と追加の Identity Number(シリアル番号など)によって、そのデバイスネームが全世界でまったく固有のものになります。
  • 異なる CA が同じ機能を持っている場合は機能インスタンスが必要になります。

 

CAN ID

J1939 メッセージは CAN2.0B の仕様をベースとしていて、Extended Frame を特定の用途で使用します。一般的な 11 ビット ID ではなく、29 ビット ID が使用されます。下図のように、J1939-21 はこの 29 ビット ID 内でフィールドを定義します。

J1939-Technology-Identifier 

図:構造パラメーターグループ

 

  • 最初の 3 ビット(Priority フィールド:P)で、プライオリティの低いメッセージよりも重要度が高いメッセージが確実に先に送られるように、ネットワークにおけるそのメッセージのプライオリティを定義します。P = 0 はプライオリティが最も高いことを示します。
  • Extended Data Page ビット(EDP)と Data Page ビット(DP)を使用することで、J1939 メッセージ(Parameter Group)に対して 4 つの異なる「Data Page」を選択することができます。

    EDP        DP       説明
    0              0              SAE J1939 パラメーターグループ
    0              1              NMEA2000 定義
    1              0              SAE J1939 予約
    1              1              ISO 15765-3 定義

  • PDU Format フィールド(Protocol Data Unit Format、PDU F)は、そのメッセージがネットワーク上の特定のデバイス向けであるのか、ネットワーク全体向けであるのかを定義します。PDU F < 239 の場合、メッセージは特定のデバイス向けであり、PDU F >= 240 はすべてのデバイス向けであることを示します。
  • PDU SpecificPDU S)フィールドの定義は、PDU F フィールドの値に基づきます。

    A.) 特定のデバイス向けのメッセージ(PDU F < 239)である場合、PDU S はそのデバイスのアドレスとして解釈され、PDU S フィールドは「Destination address」フィールド(PDU 1)と呼ばれます。

    b.) すべてのデバイス向けのメッセージ(PDU F >= 240)である場合、PDU S は「Group Extension」フィールドとして解釈されます。この Group Expansion(PDU 2)は、使用できるブロードキャストメッセージの数を増やすために使用されます。

  • CAN ID の最後の 8 ビットは、そのメッセージを送信するデバイスのアドレスを識別する「Source Address」フィールドと呼ばれます。

 

アドレスクレーム

CA はアドレスを使用する前にネットワークでそのアドレスを使用することを宣言する必要があり、それをアドレスクレーム(ACL)と呼びます。 
ここでは固有のデバイスネームを使用することで、アドレス割り当てにおける競合を解決します。数値が小さければ小さいほど、プライオリティが高いことを示します。CA は起動時に「Address Claim PGN」(ACL, PGN 00EE00h)を送信し、あらかじめ指定した待機時間のあいだ回答を待ちます。その間にほかの CA が同じアドレスの使用を宣言しなかった場合、その CA は通常の通信を開始することができます。

J1939-Technology-Address-Claiming 

図:アドレスクレームのプロシージャ

 

ネットワーク上で別の CA が同じアドレスをすでに使用している場合、アドレスの競合が発生します。より高いプライオリティがデバイスネームに含まれている CA が、そのアドレスを取得します。その CA が持つ Address Capability によってプロセスが異なります。

CA に「non self-configurable」の Address Capability がある場合、「Source Address」0(254)の「Cannot Claim Address」PGN を送る必要があります。送らなかった場合は、フリーアドレス(128-247)のアドレスプールから自身で新しいアドレスを取得します。

 J1939-Technology-Address-Claiming-Conflict

図:アドレス競合がある場合のアドレスクレームのプロシージャ

 

J1939 メッセージ(パラメーターグループ)の例

 

名称:エンジンの温度
- PG Number:65262 (FEEE Hex)
- PDU Format:254 (FE Hex)
- PDU Specific:238 (EE Hex)
- Default Priority:6
- 伝送速度:1 s
- データ長:8 バイト

データの説明
Byte 1:エンジン冷却水温度
Byte 2:燃料温度
Byte 3、4:エンジンオイル温度
Byte 5、6:ターボオイル温度
Byte 7:エンジン中間冷却器温度
Byte 8:未定義

 

 

大きなデータブロックのフラグメント送信

SAE J1939 では、8 バイト以上のデータを伴うメッセージは「フラグメント送信」で送られます。サブスクライバー指向の通信(ピアツーピア)とグローバル通信(ブロードキャスト)の 2 つに分類されます。

 

ピアツーピア

ピアツーピア通信では、送信先アドレス(Destination Address)が指定されます。データは特定のサブスクライバーを宛先とし、次のように伝送が確認されます。

  • ピアツーピア通信は、送信可(CTS)メッセージを用いて受信側によって制御される
  • 送信側が伝送できるのは、受信側の CTS(0-255)で指定された数のデータセグメントのみ
  • 受信側は「Hold」機能(データセグメントがゼロの CTS)を使って情報の流れを保留することができる
  • 送信側が「メッセージの末尾」(EOM)を受け取ると、転送が成功したことになる
  • ピアツーピアのメッセージ
    - Request To Send(RTS:送信要求)
    - Clear To Send(CTS:送信可)
    - Connection Abort(CA:接続中止)
    - End of Message Acknowledgement (EOM:メッセージ末尾の確認)
    - Data Transfer Message(DTM)

J1939-Technology-Peer-to-Peer

図:ピアツーピアメッセージ

 

ブロードキャスト

ブロードキャストとは、確認なしの通信を意味します(フロー制御なし)。送信側/発信側はメッセージの受信側を認識していません。次の手順で行われます。

  • 伝送の開始が「Broadcast Announce Message」(BAM)によって通知されるこのメッセージには、伝送されるデータのバイト数、セグメント数、パラメータグループ数が含まれる
  • 見込みのあるすべての受信側に、通知されたデータブロックの受け取りを準備する十分な時間を与えるため、送信側は BAM の送信後 50 ミリ秒が経過してからのみ最初のデータセグメントを送ることができるさらに、各データセグメント間には 50 ミリ秒の間隔を必要とする
  • 受信側にメッセージ受け取りの問題がある場合でも、一般的に受信側は 1 つだけではないため、「Connection Abort」での伝送中止はできない
  • ブロードキャストメッセージ
    - Broadcast Announce Message(BAM)
    - Data Transfer Message(DTM)

J1939-Technology-Broadcast

図:ブロードキャストメッセージ