J1939プロトコル

J1939は、コントローラエリアネットワーク（CAN）をベースにした上位層プロトコルです。CAN自体は一般的な自動車や小規模な産業用途の通信には十分適していますが、ネットワーク管理に関してはいくつかの欠点があります。これらの機能を追加するために、物理層としてのCANは、上位層プロトコルと呼ばれる追加のソフトウェアによって拡張することができます。

J1939プロトコルは、CANの29ビットメッセージ識別子を最大限に活用するように設計されています。J1939は、無数のプロトコル機能に依存するのではなく、事前定義されたパラメータテーブルを使用することで、実際のプロトコルを分かりやすいレベルに維持しています。

最大ネットワーク長 40 メートル (約 120 フィート)、ボー レート 250 kBit/秒、最大ノード数 (30) はプロトコルによる自主的な制限であり、すべてを安全側に保ち、実行時に発生する可能性のある問題を防止しようとする意図によるものであることを強調する必要があります。

PGNとSPN

J1939の主な特徴は、膨大な数の事前定義された車両データと制御機能を指すサスペクトパラメータ番号（SPN）とパラメータグループ番号（PGN）の使用です。PGNとサスペクトパラメータ番号（SPN）の定義は、J1939標準規格集の大部分を占めています。SPNは、パラメータグループ内の各パラメータのデータ型と用途を定義します。パラメータグループ番号は、29ビットのCANメッセージ識別子に埋め込まれます。

図1 疑わしいパラメータ番号、パラメータ グループ、およびパラメータ グループ番号の使用方法を示します。

J1939は29ビットの識別子のみを使用します。この識別子は、バス上のデータの送信元、そして場合によっては送信先を識別するために使用されます。29ビットの識別子の構造を図2に示します。

各PGNは、予約済み、データページ、PDUフォーマット、PDU固有という4つのフィールドで構成されます。予約済みは常に0に設定されます。データページは、規格で定義されているPGNの数を増やすために使用されます。現在、PGN範囲全体が埋められていないため、データページはまだ0のままです。

PDUフォーマットは、メッセージがピアツーピアかブロードキャストかを決定します。PDUフォーマットが240未満（PDU1とも呼ばれます）の場合、メッセージはピアツーピアであり、宛先アドレスはPDU Specificフィールドに格納されます。一方、PDUフォーマットが240以上（PDU2とも呼ばれます）の場合、メッセージはブロードキャストであり、PDU Specificフィールドは送信可能なパラメータグループの範囲を拡大するために使用されます。

PDU1はピアツーピア通信ですが、これらのメッセージは宛先アドレス255を使用してブロードキャストできます。255番地はまさにこの目的のために予約されており、ECUがそのアドレスを占有することはできません。

リクエストメッセージ

J1939プロトコルは、データ要求として機能する特別なPGNを定義しています。0x00EE00値を持つPGNは、要求されたPGNがメッセージデータに埋め込まれたデータ要求として解釈されます。

PDUフォーマット（0xEEまたは238）が240未満であるため、要求はピアツーピアです。PDU Specificは要求の宛先アドレスを定義します。宛先アドレスとして255が使用されている場合、要求はブロードキャストされ、ネットワーク内のすべてのノードが要求に応答する必要があります。

要求への応答は、要求されたPGNを含むメッセージです。要求されたPGNがノードでサポートされていない場合、ノードはNACK（Not Acknowledge）メッセージを送信します。要求がブロードキャストされる場合、NACKは不要です。

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

J1939では、最大メッセージ長は1785バイトと定義されています。トランスポート層としてのCAN自体は8バイトを超えるメッセージをサポートしていないため、メッセージを8バイトサイズのメッセージシーケンスにまとめる必要があります。

トランスポートプロトコルは、これらのメッセージの転送方法と、目的のノードとの接続を確立する方法を定義します。このために、接続管理PGN（0x00EC00）とトランスポートプロトコルPGN（0x00EB00）という2つのPGNが定義されています。

宛先アドレスに応じて、2 種類のトランスポートが定義されます。宛先が 255 の場合はマルチパケット ブロードキャストが使用され、宛先が 0 から 253 の間の場合はマルチパケット ピアツーピアが使用されます。

マルチパケットブロードキャストはよりシンプルで、接続管理PGNを使用してブロードキャストアナウンスメッセージ（BAM）を送信し、トランスポートプロトコルPGNを使用してデータメッセージを送信することで構成されます。BAMメッセージの送信後、および各データメッセージ間で、送信ノードは50～200ミリ秒待機します。

マルチパケットピアツーピアでは、送信ノードと受信ノード間のハンドシェイクメカニズムが必要です。送信ノードがメッセージを送信する場合、まず受信ノードに送信要求（RTS）メッセージを送信します。受信ノードは、接続を受け入れる場合は送信可（CTS）メッセージで応答し、拒否する場合は接続中止メッセージで応答します。CTSメッセージには、次のパケットのインデックスが格納されています。次に、送信ノードはトランスポートプロトコルPGNを使用してパケットを送信し、受信ノードは次のパケットインデックスを含むCTSメッセージで応答します。このハンドシェイクメカニズムは、最後のパケットが受信され、受信ノードがメッセージ終了確認応答を送信して接続が閉じられるまで使用されます。RTS、CTS、メッセージ終了、および接続中止は、接続管理PGNを使用して交換されます。

ネットワーク管理

標準的なアドレス要求手順では、すべてのノードが電源投入時にアドレス要求メッセージを送信することが規定されています。このメッセージを送信することで、ノードはネットワーク内の他のすべてのノードに、使用するアドレスを通知します。他のノードが既にこのアドレスを使用している場合もあります。その場合、2つのノードはNAME値を比較します。NAMEは、各アドレス要求メッセージと共に送信される64ビットデータであり、各ノードの機能を表します。NAME値が小さいノードがそのアドレスを保持し、もう一方のノードは別のアドレスを使用する必要があります。

アドレス衝突が発生し、ノードがアドレスを変更する必要がある場合、2つの状況が考えられます。ノードが任意アドレス対応の場合、何らかのメカニズムを用いて別のアドレスを選択し、アドレス要求メッセージを再送信します。J1939では、この処理を容易にするために、ノードの機能の種類ごとに特別なアドレス範囲が定義されています。ノードが任意アドレス対応でない場合、アドレス254（NULL）を取得し、この値を含むアドレス要求メッセージを送信することで、アドレスを要求できないことを示します。アドレス254を持つノードは、ネットワークにデータを送信しません。

任意アドレス対応でないノードは、有効なアドレスを決定するために何らかの外部メカニズムを必要とします。このアドレス定義は手動で行うことも、どのノードがどのアドレスを使用するかを定義するコマンドアドレスメッセージを送信する別のノードによって行うこともできます。

診断メッセージ

J1939は、ネットワーク上のデバイスの診断情報の監視、テスト、およびクリアに使用できる19種類の診断メッセージを提供します。これらのメッセージは一般にDMメッセージと呼ばれます。現在、Typhoon HILはDM1診断メッセージのみをサポートしています。

DM1メッセージは、アクティブな診断トラブルコード（DTC）のリストを提供します。これらは、デバイス上で現在アクティブなDTCです。

1つのメッセージで、1つまたは複数の診断トラブルコード（DTC）を送信できます。1つのDTCがアクティブな場合、メッセージはLS、DTC（ランプステータス、診断トラブルコード）の形式で送信され、複数のDTCがアクティブな場合、メッセージはLS、DTC1、DTC2、DTC3、…、DTCnの形式で送信されます。

DM1 メッセージは可変長であるため、このタイプのメッセージを受信するには、 「DM1 メッセージの受信」で説明されている別の方法が必要です。

DM1診断メッセージ

アクティブ診断トラブル コード メッセージ (DM1 メッセージとも呼ばれます) は、診断ランプの状態と現在アクティブな診断トラブル コード (DTC) を伝えます。

Typhoon HILツールチェーンにおけるJ1939プロトコルの実装

J1939がCANバスプロトコルの拡張であるのと同様に、Typhoon HILツールチェーンのJ1939コンポーネントは既存のCANバスコンポーネントの拡張です。J1939 SendコンポーネントとJ1939 Receiveコンポーネントの使用方法は、CANバスSendコンポーネントとCANバスReceiveコンポーネントと同じであり、同じハードウェアデバイス（ HIL101、HIL404、HIL602+、HIL604、HIL506、HIL606）でサポートされています。

次のいくつかのセクションでは、J1939 に固有の機能についてのみ説明します。

CANセットアップ

J1939コンポーネントはCANバスコンポーネントの修正版であるため、CANコントローラのボーレートと実行速度を定義するために、回路図にCANセットアップコンポーネントを配置する必要があります。CANセットアップコンポーネントの使用方法については、こちらをご覧ください。

J1939 送信

J1939 送信 (J1939 PGN 送信) コンポーネントは、送信するメッセージの形式、値、およびサイズを指定するために使用されます。

コンポーネントは表 2に示され、J1939 送信ダイアログ ウィンドウは図 3に示されます。

表2 J1939送信

成分	コンポーネントのプロパティ
J1939 送信	CANコントローラ データ入力 設定ファイル メッセージを選択 IDタイプ 優先度 データページ PDUフォーマット 宛先アドレス/グループ内線 宛先アドレスの定義 送信元アドレス（ECU ID） 送信元アドレスの定義 メッセージの長さ 送信タイプ イベントで タイマーオン リクエストに応じて 送信期間

J1939送信コンポーネントのパラメータの説明は表3に示す。

J1939 送信信号の定義については、CAN バス送信信号の定義を参照してください。

回路図には多数のJ1939送信コンポーネントが存在する可能性があり、各コンポーネントは送信するJ1939 PGNメッセージを1つずつ記述します。複数のメッセージを送信するためにモデルにJ1939送信コンポーネントを追加する場合は、すべてのメッセージに一意のIDが割り当てられていることを確認してください。

ダイアログウィンドウで定義されたメッセージ長に応じて、J1939送信コンポーネントは異なるメッセージタイプを使用します。メッセージ長が8バイト未満の場合は、CANバス送信コンポーネントと同様に、通常の方法でメッセージが送信されます。メッセージ長が8バイトを超える場合は、「トランスポートプロトコル」で定義されたトランスポートプロトコルが使用されます。

コンポーネントへのecu_id入力は、送信元アドレスの値として機能します。ECU ID値はCANメッセージにパックされた値としてのみ使用され、システム全体のECU IDとして認識されることはありません。つまり、ECU ID値を変更しても、ネットワーク管理で定義されているアドレスクレーム手順はトリガーされません。

アドレス要求手順では、 J1939 仲裁コンポーネントを使用する必要があります。

J1939メッセージの送信時、ECU ID値254は禁止されています。ecu_id入力でこの値が検出された場合、メッセージは送信されません。

J1939 受信

J1939 受信（J1939 PGN 受信）コンポーネントは、CAN ネットワークを介して受信したメッセージを解凍するために使用されます。

コンポーネントは表 4に示され、J1939 受信ダイアログ ウィンドウは図 5に示されます。

J1939 受信信号の定義については、CAN バス受信信号の定義を参照してください。

回路図には多数のJ1939受信コンポーネントが存在する可能性があり、これらのコンポーネントはすべて、定義されたID値を持つJ1939メッセージの受信に使用されます。J1939受信コンポーネントで定義されたID値と一致しないID値を持つメッセージは無視されます。

新しいメッセージが受信されるたびに、rcv_cnt 値は 1 ずつ増加します。

DM1メッセージを受信

DM1 メッセージは可変長であるため、このタイプのメッセージを受信するには別の方法が必要です。

すべてのCANベースコンポーネントでは信号定義が静的であるため、受信可能なDTC信号の最大数を定義する必要があります。つまり、常に受信するわけではないDTC1、DTC2、DTC3…といった信号をテーブルに追加する必要があります。これは図7に示されています。この構成では、最大13個のDTC値を受信できます。

J1939仲裁

J1939 仲裁コンポーネントは、ネットワーク管理で定義されているアドレス要求プロセスを実行するために使用されます。

J1939アービトレーションコンポーネントは1つのECU IDを定義します。ネットワーク上の各ECUは起動時にアドレス要求手続きを実行する必要があります。J1939アービトレーションコンポーネントはこれを可能にします。

J1939仲裁コンポーネントのパラメータの説明は表7に示す。

ダイアログウィンドウ内のパラメータを組み合わせることで、アドレス取得手順で使用されるECU NAME値が作成されます。ECUの優先アドレスは、J1939アービトレーションコンポーネントへの入力信号として定義されます。

シミュレーション開始時に、J1939アービトレーションコンポーネントはネットワーク上にアドレス要求メッセージを送信し、250ミリ秒間待機します。ネットワーク上の他のノードがこのメッセージに応答しなかった場合、 preferred_addr入力の値がecu_id出力に渡され、この値はJ1939送信コンポーネントと受信コンポーネントでECU IDとして使用できます。

他のノードがAddress Claimedメッセージを送信し、NAME値がJ1939 Arbitrationコンポーネントで定義された値より小さい場合、そのコンポーネントはArbitrationに敗れます。その結果、Cannot Claimメッセージが送信され、 ecu_id値は254になります。J1939 Sendコンポーネントのecu_id値として254を使用すると、メッセージの送信がブロックされます。

J1939 仲裁コンポーネントは、単一アドレス対応 ECU として動作します (NAME のプロパティ値に関係なく)。つまり、コンポーネントが提示されたアドレスを要求できない場合、優先アドレス値が変更され、要求手順全体が再度トリガーされるまで、値 254 を出力します。

コマンド アドレス メッセージもサポートされていません。

設定ファイルを使用してCANメッセージを指定する

送信コンポーネントと受信コンポーネントはどちらも、DBCファイルまたはARXMLファイルをインポートしてメッセージを定義できます。基本的な動作はどちらのコンポーネントでも同じですが、ここではCANバス送信コンポーネントについてのみ説明します。

設定ファイルを読み込むには、「データ入力」プロパティで「設定ファイル」を選択し、 「ファイルの選択」ボタンを使用して目的のファイルを選択します。ファイルが正しく解析されると、 「メッセージの選択」コンボボックスにファイル内のメッセージ名が表示されます。異なるメッセージを選択すると、ダイアログ内のメッセージとシグナルのパラメータが変更されます。例を図10に示します。

DBCファイルまたはARXMLファイルを使用してCANメッセージを定義する場合、すべてのメッセージおよび信号パラメータは編集不可となります。データ入力をダイアログウィンドウに変更するとパラメータは編集可能になりますが、その後データ入力を構成ファイルに戻すと、パラメータは構成ファイルの値に戻ります。

Schematic API を使用してコンポーネントのプロパティ値を変更する

カスタムコンポーネントダイアログは、CANメッセージのパラメータを簡単に定義できるように設計されています。これらの値の変更は、標準の回路図API関数を使用しても可能ですが、変更された方法となります。つまり、送信メッセージと信号情報を除くすべてのプロパティは標準的な方法で変更されます。送信メッセージはPython辞書型として指定し、要求情報はPython辞書型のリストとして指定する必要があります。

transmit_type = {
    "On event": True,
    "On timer": False
}
mdl.set_property_value(mdl.prop(can_component, "transmit_type"), transmit_type)

signals = [
    {"name": "signal0", "start_bit": 0, "length": 8, "byte_order": "Little Endian", "data_type": "uint", "mux_type": "None"},
    {"name": "signal1", "start_bit": 8, "length": 8, "byte_order": "Little Endian", "data_type": "uint", "mux_type": "Muxer"},
    {"name": "signal2", "start_bit": 16, "length": 8, "byte_order": "Little Endian", "data_type": "uint", "mux_type": "Muxed", "mux_val": "0"},
    {"name": "signal3", "start_bit": 16, "length": 8, "byte_order": "Little Endian", "data_type": "uint", "mux_type": "Muxed", "mux_val": "1"}
]
mdl.set_property_value(mdl.prop(can_component, "signals"), signals)

dbc_file_path = r"C\dbc_files\ford_fusion_2018_pt.dbc" mdl.set_property_value(mdl.prop(can_component, "file_path"), dbc_file_path) mdl.set_property_value(mdl.prop(can_component, "choose_message"), "Lane_Keep_Assist_Control")

CAN実行レートの説明

このセクションでは、これらのそれぞれの値と、それらの相互関係を明確にすることを目的としています。

まず、CAN通信プロトコルを使用するすべてのモデルにおいて、2つの側面を区別することが重要です。信号処理の側面と、CAN通信プロトコル自体の処理です。モデルのコンパイル時に、回路図上のすべての信号処理コンポーネントは、1つのCPUコアで実行される1つのアプリケーションに統合されます。一方、すべてのCANコンポーネント（信号処理ライブラリの一部であっても）は、別のCPUコアで実行される別のアプリケーションに統合されます。これら2つのアプリケーションは、それぞれ異なるエンティティです。

すべての信号処理コンポーネント（CANコンポーネントを含む）には実行レートプロパティがあります。接続され、論理関数を実行するすべてのコンポーネントは、同じ実行レート値を共有します。実行レート値は、その関数が実行される頻度を定義します。

CANxコントローラの実行レートはCANアプリケーションに固有の機能を持ちますが、CAN関数が呼び出される頻度を定義します。

各CAN送信コンポーネントには、メッセージがネットワークに送信される頻度を定義する送信周期プロパティがあります。送信周期とCANxコントローラの実行速度は直接相関しており、 CANxコントローラの実行速度は送信周期の粒度値として機能します。つまり、 CANxコントローラの実行速度が1msに設定されている場合、送信周期は1msの整数倍、つまりN*1msのみとなります。同様に、 CANxコントローラの実行速度が3msに設定されている場合、送信周期はN*3msのみとなります。

ボーレートは、CAN規格で定義されている唯一の値です。この値はビット/秒で表され、2つのCANコントローラ間でメッセージが中継される速度を定義します。送信周期とボーレートの違いは、メトロノームの例で簡単に説明できます。メトロノームは定期的にクリック音を発しますが（送信周期）、そのクリック音は音速でリスナーに伝わります（ボーレート）。

図 11 は上で説明した内容をすべて示しています。

仮想HILサポート

Virtual HILは現在このプロトコルをサポートしていません。非リアルタイム環境（例：ローカルコンピュータでモデルを実行する場合）を使用する場合、このコンポーネントへの入力は破棄され、このコンポーネントからの出力はゼロになります。