1. 15765 プロトコルの概要
簡単に言えば、15765 プロトコルは次のことを指します。
CAN2.0A/B プロトコル (ISO11898 プロトコルリンク層とも呼ばれます) に基づく
ハードウェアインターフェースのアプリケーション層通信プロトコル、
一般的な車両診断サービスを実装するために使用されます。
ISO11898プロトコルについては、以下の図を参照してください。
「CANバスプロトコル解説」ドキュメントを検索して参照してください。
以下を指定します。
1. 120 オームの抵抗をバス CAN_H と CAN_L の間に接続する必要があります。
2. CAN バスがリセッシブの場合 (つまり、ロジック レベルが 1 の場合)、バスの電圧差は 0V です (図のデフォルト レベルは 2.5V)。
CAN バスが優勢な場合 (つまり、ロジック レベルが 0 の場合)、バス電圧の差は約 2.0 V です (表示されているレベルは 3.5 V と 1.5 V)。
3. バス通信速度は 125K ～ 1M ビットレート/秒です。
2. プロトコルデータユニット PDU
これはハードウェア レベルでのことです。
15765 の 1 PDU は CAN データの 1 フレームです。これには主に、フレーム ID と (最大 8) バイト データが含まれます。
フレームIDは29ビットの拡張フレームと11ビットの標準フレームに分かれます。
全体的なフォーマットは次の図に示されており、具体的な内容は CAN2.0 プロトコル (ISO11898) を参照する必要があります。
3. サービスデータユニット FDU
FDU は 1 ～複数の PDU で構成されており、その構成方法は単純に 15765 プロトコルとして理解できます。
PDU には 4 つのタイプがあります。
1) シングルフレーム
フレーム数は 1、つまりデータは 8 バイトを超えません。
最初のバイトは長さを示し、その後にデータが続きます。
02 3E 00 など //長さは 2、診断 ID は 0x3E、サブデータは 00
2) 複数フレームの最初のフレーム
フレーム数が 1 より大きい、つまりデータが 8 バイトを超えています。
最初のバイトの最初の 4 ビットは 1 で、それがマルチフレームの最初のフレームであることを示します。
最初のバイトは 8 ビット左にシフトされ、2 番目のバイトはデータ長を示すために追加されます。つまり、最大データ サイズは 4095 バイトです。
例: 10 08 01 02 03 04 05 06 //複数のフレームの最初のフレーム、データ長は 8、最後の 6 つは有効なデータ
3) マルチフレームデータフレーム
最初のバイトの最初の 4 ビットは 2 で、これがマルチフレームの最初のフレームであることを示します。
最初のバイトの最後の 4 ビットはシリアル番号を表し、最初のパケットは 1 から始まり、以降のパケットは順に増加し、増分が 15 を超えると 0 から始まります。
10 08 01 02 03 04 05 06 //最初のフレーム
30 00 00 00 00 00 00 00 //フロー制御フレーム
21 07 08 //データフレーム
4) マルチフレームフロー制御フレーム
最初のバイトの最初の 4 ビットは 3 で、マルチフレーム フロー制御フレームであることを示します。
最初のバイトの最後の 4 ビットは応答コードを表し、00 は正常を表し、データを継続的に送信できます。そうでない場合は、後続の送信を停止する必要があります。
3 バイト目は通常マルチフレームの送信遅延を示し、通常 00 は後続のマルチフレーム データ フレーム前の送信間隔が 0 であることを示し、1 は送信間隔が 1ms であることを示します。
他の場所では、さまざまなメーカーの定義が同じではなく、フロー制御フレームを使用していないところもあります。
4. 15765 のパッケージ化とアンパックの実装
4.1 環境を準備する
デバイスを 2 台用意し、CAN high と CAN low を接続します。デフォルトでは、CAN-1M ボーレート通信が設定され、有効になっています。
データを送信します (イニシエーター送信 ID は 18FFFFFF を使用します):
{
"cmd":"get_vol",
"from":"master",
"to":"device"
}
压缩：
{"cmd":"get_vol","from":"master","to":"device"}转Hex：7b22636d64223a226765745f766f6c222c2266726f6d223a226d6173746572222c22746f223a22646576696365227d
データ長は 47、つまり 0x2F です。
レスポンスデータ（受信側のレスポンスIDは18FFFFFEを使用）：
{
"cmd":"23.89v",
"from":"device",
"to":"master"
}
压缩：
{"cmd":"23.89v","from":"device","to":"master"}16 進数に変換:
7b22636d64223a2232332e383976222c2266726f6d223a22646576696365222c22746f223a226d6173746572227d
データ長は 46、つまり 0x2E です。
4.2 パッケージ
送信データの長さが 8 を超えるため、グループ化にはマルチパケット モードが必要です。
最初のパッケージとデータ パッケージは次のように逆アセンブルできます。
发起端：
10 2F 7b 22 63 6d 64 22 //发送
30 00 00 00 00 00 00 00 //响应
21 3a 22 67 65 74 5f 76 //发送
22 6f 6c 22 2c 22 66 72
23 6f 6d 22 3a 22 6d 61
24 73 74 65 72 22 2c 22
25 74 6f 22 3a 22 64 65
26 76 69 63 65 22 7d 00 //空余1字节填充00
接收端：
10 2E 7b 22 63 6d 64 22 //发送
30 00 00 00 00 00 00 00 //响应
21 3a 22 32 33 2e 38 39 //发送
22 76 22 2c 22 66 72 6f
23 6d 22 3a 22 64 65 76
24 69 63 65 22 2c 22 74
25 6f 22 3a 22 6d 61 73
26 74 65 72 22 7d 00 00イニシエータープロセス:
まず 10 フレームを送信し、30 フレームの応答を待ちます。
30 フレームの肯定応答を受信した後、21 から 26 までの合計 6 パケットのデータが順番に送信されます。
次に、ID を受信するまでさらに 10 フレーム待ちます。30 フレームを受信したらすぐに応答します。
次に、受信した 2x データ フレームを読み取るかキャッシュし、有効なデータを抽出して、Json API で解析します。
4.3 開梱
送信側のデータは、組み立てられたパッケージのデータのみが送信されます。
受信処理の際には一つ一つ判断する必要があります。
参照コードは次のとおりです。
int ISO15765CanFrameRxDeal(uint8_t data, uint32_t id)
{
switch(data[0]&0xF0)
{
case 0x00://单帧
//单帧可以当场处理掉
break;
case 0x10://首帧
//1,提取要接收的长度
//2,根据长度或这包数申请内存buf(或者创建/清空数据队列)
//3,缓存第一包的6byte数据
//4,发送30帧响应
break;
case 0x20://数据帧
//根据包序号判断是否接收完毕
//将数据缓存到buf(或者将数据写入队列)
break;
case 0x30://流控帧
//发送完10帧后等待30帧,一般判断是不是30帧正响应即可
break;
}
}5. J1939プロトコル
1939 と 15765 のハードウェア レベルは、1939 が 250K ボー レート通信を規定していることを除いて、まったく同じです。
商用車やトラック、バスのネットワーク通信に使用されており、ブロードキャストネットワーク形式であり、車両内での通信には一般に6/14ピン-250Kボーレートを使用することが規定されています。
商用車では下図のように、
メーター、エアコン、後処理装置、トラベルレコーダー、エンジン、ギアボックスなどは、必要なデータをブロードキャストの形式で CAN ネットワークに送信する必要があります。よく見かける自動車のインパネは、実はブロードキャストフレームIDデータを監視・解析しています（自動車の通信内容は容易に解読できます）。
異なるオンボードモジュールについて、異なるモジュールのデータを区別する方法、
1 つ目はフレーム ID と PGN です。
1939 年の PDU の場合、フレーム ID とデータ部分は次のように定義されています。
1) 1939 固定 250K 通信、フレーム ID は 29 ビット (4 バイト) を使用します。
2) フレームIDの先頭バイトの有効5ビットのうち、
最初の 3 ビットは P アービトレーション優先度として定義されます
4 ビット目と 5 ビット目は拡張データ ページとデータ ページとして定義されます。
3) フレーム ID の 2 バイト目は、PDU 形式である PF を示します。
PF 値の範囲が 0 ～ 239 (0x00 ～ 0xEF) の場合は PDU1 形式であることを示し、範囲が 240 ～ 255 (0xF0 ～ 0xFF) の場合は PDU2 形式であることを示します。
4) フレーム ID の 3 バイト目は PS、PDU 固有を示します。
PUD1 形式の場合、このフィールドはフレームの宛先アドレスを示し、PDU2 形式の場合、グループ拡張 GE を示します。
5) フレーム ID の 4 バイト目は SA、つまり送信元アドレスを示します。
送信元アドレスはどこから来たのかを示しており、契約では、00 はエンジン、3D は後処理、17/21 は計測器などと規定されています。
簡単に言えば、PGN はフレーム ID の 2/3 バイトである PF と PS で構成されます。(完全な PGN 定義はEDP+DP、PF、PS の3 バイトで構成されますが、EDP と DP は通常すべて 00 であるため、フレーム ID の最初のバイトは無視されます)
実際のアプリケーション シナリオでは、車のブロードキャスト ID を監視し、PGN ルールとプロトコルに従って対応するデータ フローまたは障害コード分析ルールを照合し、データを分析します。
たとえば、商用車には通常0x0CF00400 ブロードキャスト データがあり、その有効データは 8 バイトです。PGN の場合は00F004。
IDで直接照合することも可能です。リトル エンディアン順で 4 番目と 5 番目のバイトを抽出し、80 で割って車のエンジンの速度値を取得します。
同様に、1939 プロトコルには複数のデータ フレームがあり、一般にその内容は障害コード データと複雑なデータまたは拡張データです。
PGN 00FECA 電流障害を示します
PGN 00FECB は歴史的な障害を示します
PGN 00FECC はクリア障害を意味します
車のマルチフレーム データは通常 2 つのフレーム ID で表され、1 つのフレーム ID は最初のフレームを表し、1 つのフレーム ID はデータ フレームを表します。
最初のフレームには有効なデータが含まれていません。最初のバイトは通常、さまざまなアドレッシング モードを示す 10 または 20、2/3 バイトは長さを示し、4 番目のバイトはパケット数を示します。5 バイトは埋められ、6/7/8 bytes PGN を設定します。
データフレームの最初のバイトはパケット数を示し、残りの 7 バイトは有効なデータです。