前言

在前篇文章控制器區域網路（CAN bus）特性與重點，講述了 CAN 的基本特性、CAN 的種類、差異及資料幀的內容。

在傳統的資料傳遞過程中，通常是透過定義好特定的 ID，與定義了 8 個位元組資料分別代表什麼訊號，並搭配 DBC 檔案進行詳細說明與解碼。

CAN 協定本身只定義了如何在網路上傳遞資料，並沒有詳細規定資料的內容和格式。因此，需要引入一些高階協定（Higher Level Protocol，HLP），例如CCP/XCP、CANopen、AUTOSAR、J1939等，以滿足不同的需求和應用場景。

以未使用 HLP 的 CAN 為例子，我們可能定義 ID 為 0x100 的前 4 個位元組表示車速，範圍為 0 至 150，單位是 km/h；後 4 個位元組表示檔位資訊，其中 1000 表示 P 檔，0100 表示 D 檔，依此類推。不同廠商會有各自不同的定義，通常會使用一張大型的 Excel 表格或 DBC 檔案來記錄並說明解碼方式。

SAE J1939 介紹

SAE J1939 協定由美國汽車工程師協會（society of automotive engineers，SAE）制定。其中的一些特性在於：

• 使用 29 位元的擴展識別碼（Extended Identifier）。
• 使用 CAN 2.0，傳輸速率為 250 kbps 或 500 kbps。(*)
• 具有點對點尋址（節點尋址）和全域尋址（訊息尋址）。
• 多封包訊息最多可傳輸 1785 位元組。
• 通過自己的網路管理進行網路訪問控制。
• 用於整體車輛通訊的標準化訊息。
• 允許特定於製造商的訊息定義。
• 定義自己的診斷介面。

由於 J1939 主要使用擴展幀進行通訊，識別碼從原本的 11 位元擴展到 29 位元，因此可以在識別碼欄位中包含一些進階資訊，如優先權、資料頁、群組編號等參數。

SAE J1939/14 物理層標準 首次發佈於 2011，定義了 500 kbps 的速度。 SAE J1939/22 CAN FD 資料連結層 定義了 CAN FD 作為 J1939 的傳輸曾實現，在現實生活中（≈2024），多數採用的還是 CAN 2.0 作為標準的傳輸層。

封包格式

SAE J1939-21 文件定義了 29 位元 CAN ID 如何規劃，如下表所示一共為 29 個位元：

• Priority：使用 3 個位元確定訊息在網路傳輸中的優先權，數值越低優先權越高，範圍為 0 到 7。所有控制相關訊息的預設優先權為 3，對於其他資訊、專有、請求和確認訊息的預設優先權為 6。當 PGN 被添加到應用層文件時，會為其分配一個建議值，並且優先權也可以根據 OEM 的需求進行調整。

• Extended Data Page：EDP 與 DP 一起用於確定 CAN ID 的結構。在 SAE 規範中，EDP 的預設初始值為 0。而對於其他協定如 ISO 11992，則會將 EDP 與 DP 同時設為 1，以區分 J1939 封包格式與其他協定的格式，並且後續的格式可以不遵循 J1939 的格式。

• Data Page：與 EDP 一起用於確定 CAN ID 結構。並可整理為以下定義：

  EDP	DP	描述
  0	0	SAE J1939 第 0 頁 PGNs
  0	1	SAE J1939 第 1 頁 PGNs, SAE J1939 NMEA 2000®
  1	0	SAE J1939 （保留）
  1	1	ISO 11992 診斷（非 J1939 佈局！）

• PDU Format：一個 8 位元的欄位，用來決定 PS 的格式。範圍為 0 ~ 255。

• PDU Specific：

  • 當 PF < 240 時，PS 為目標地址（Destination address，DA），即將該封包傳遞給特定的目標位置，這也稱為 Specific PGN 或是 PDU1。其中，若 DA 為 0xFF，則稱為全域廣播地址（Global Broadcast Address）。
  • 當 PF ≥ 240 時，PS 為組擴展（group extension，GE），表示訊息為廣播訊息，又可稱為 Global PGN 或是 PDU2。

• PGN 總共為 18 個 bit，由 {EDP, DP, PF, PS} 組成。

  其目的是用來識別參數組號。類似於非擴展幀的 CAN ID，在非擴展幀中，我們用 CAN ID 來表示訊號，例如 0x100 代表車速，0x101 代表引擎狀態。PGN 在 J1939 協議中的作用類似於非擴展幀中的 CAN ID，都是用來標識訊息的類型和內容。

• Source Address：網路上每個 SA 僅能對應一個設備，因此 SA 欄位可以確保 CAN ID 的唯一性。根據 SAE J1939-81 標準，其中定義了防止 SA 重複的步驟。

由上述可以得知 PGN 一共有：

• PF < 240 ：240 個
• PF ≥ 240 ：16 × 256 個（PF 240 ~ 255，並對應 256 個組擴展）

再加上 EDP 與 DP 可以組成為 00, 01 兩頁，所以最多可以有：[240 + (16 × 256)] × 2 = 8672 個 PGN

其中，現有標準已經規劃 PGN，如：引擎資訊等…，與製造商可以自訂的範圍如下表所示：

資料如何被定義與解碼？

SAE 已經針對 J1939 標準中的資料定義和解碼提供了詳細的規範（SAE J1939-71）。資料的定義主要依賴於 SPN（假定參數編號）。

SPN 會定義一個編號，這個編號底下會定義名稱、資料長度、資料類型、縮放因素（Factor）、位移量（offset）、範圍、標籤、單位等…。

以引擎速度為例子，J1939 定義了 PGN 61444 為電子引擎控制器1（Electronic Engine Controller 1，EEC1），優先權為 3，傳送週期 50 ms，資料長度為 8 bytes。

資料如下表所示，每一個 SPN 對應特定的變數名稱：

每個 SPN 定義了名稱、倍率（Factor）和位移量（Offset）。讀取到的原始值（RAW 值）可以透過這些定義轉換為實際數值。

例如，引擎轉速（Engine Speed）總共為 16 bits，若讀取到的原始值為 17214，則引擎的轉速為 2151.75 RPM（該標準中定義的上限值為 64255，即 8031.875 RPM）。

這些資訊最終會被整理成 DBC 檔案，用於描述這些參數，可於某些特定軟體載入，並會將錄製到的參數數值自動解碼並轉換。

以 PEAK-CAN 所提供的符號文件（Symbol file）為例，我們可以更清楚地看到資料在這 8 個 Byte 中的呈現方式，裡面定義了 SPN、位移量、解碼方式和單位等：

最後，一個 SPN 可以存在於多個 PGN 中。例如，廠商自己定義 SPN 30000 代表韌體資訊，在出廠前中可以透過 PGN 2000 讀取和寫入該 SPN。而產品出廠後，限定只能通過 PGN 20000 來讀取這個數值。

SPN 蠻多文獻會翻譯為可疑參數編號，我也不知道是在可疑什麼，現今網路上資料翻譯都為可疑，看懂就好。通俗直白地說明就是定義好一組編號，並且對應到一個變數名稱、說明他的長度、縮放因素與位移量，僅此而已。

訊息類型

SAE J1939/21 目前記錄了總共五種訊息類型。它們是：

• 命令（Command）
• 請求（Request）
• 廣播/回應（Broadcasts/Responses）
• 確認（Acknowledgement）
• 群組功能（Group Functions）

命令

命令訊息類型實際上只是一個普通的 PGN，支持兩種 PDU 格式，PDU1 用於點對點通信，PDU2 用於廣播通信。命令類型的例子包括"變速器控制"、“地址請求”、“扭矩/速度控制"等…。

請求

PGN 為 0x0EA00。請求訊息類型被用於全域或從指定目標請求特定資料（PGN），其定義如下圖所示：

當接收端收到請求時，必須作出回應，即使這意味著在請求的 PGN 不存在時需要發送否定確認（NACK）。然而，當某個特定 PGN 不被支持時，全域請求不會觸發 NACK。

廣播/回應

廣播/回應訊息類型只是一個普通的PGN，支持兩種 PDU 格式，PDU1 用於點對點通信，PDU2 用於廣播通信。它可以是未經請求的資料廣播，也可以是對命令或請求的回應。

確認

PGN 為 0x0E800。提供傳輸和響應節點之間的握手機制，以確保命令或請求得到了正確處理，當收到命令或請求的回應。

SAE J1939/21 標準中並沒有明確說明確認訊息類型（Acknowledgement Message Type）只能支持 PDU1 格式。因此，目標地址可以設置為 0xFF，從而簡化接收端資料過濾的過程。

其中 ACK 分為四種，會透過首個位元組進行判別：

• Byte 0 = 0x00，Positive Acknowledgement (ACK)
• Byte 0 = 0x01，Negative Acknowledgement (NACK)
• Byte 0 = 0x02，Access Denied (有支持 PGN，但因安全原因拒絕訪問)
• Byte 0 = 0x03，Cannot Respond (有支持 PGN，但ECU無法回應。請稍後請求數據)

群組功能

用於廠商自定義、分配的 PGN，可實現專有功能、網路管理和多包傳輸功能。

PGN 範圍：

• 0x0EF00（61184），Proprietary A
• 0x1EF00（126720），Proprietary A2
• 0x0FF00（65280） ~ 0x0FFFF（65535），Proprietary B
• 0x1FF00（130816） ~ 0x1FFFF（131071），Proprietary B2

傳送超過 8 個位元組

在傳統 CAN 中，資料長度僅能放入 8 個位元組。在 SAE J1939-21 定義了多幀傳輸方法，以傳輸超過 8 個位元組的資料長度，最多至 1785 個位元組。

在 J1939 傳輸協議中，有兩種主要方法處理多幀數據傳輸：點對點訊息和廣播訊息：

1. 請求傳送/允許傳送（RTS/CTS）： 使用 RTS/CTS 方法時，發送端會發送請求傳送（RTS）訊息給接收端，詢問是否可以傳送數據。接收端回應允許傳送（CTS）訊息表示可以接收數據。此方法為點對點的傳輸方式。
2. 廣播宣告訊息（BAM）： 使用 BAM 方法時，發送端會廣播一個宣告訊息，表示接下來將會有多個數據幀傳送。這種方式不需要接收端的回應，因此適用於需要廣播給多個接收端的情況。`

決定使用哪種方法進行傳輸，透過傳輸協議 - 連接管理（transport protocol – connection management，TPCM）進行決定，並由傳輸協議 - 資料傳遞（transport protocol – data transfer，TPDT）進行資料傳遞。

兩者對應的 PGN 分別為 TPCM：0x0EC00（60416）與 TPDT：0x0EB00（60160）。

TPCM

TPCM 中的 Byte 0 根據不同數值代表此封包的差異。

TPDT

TPDT 中的 Byte 0 用來表示序號，範圍從 1 到 255。後續的 7 個位元組用來傳遞資料，在傳遞很長的資料時，如果未滿足 7 的倍數，則使用 0xFF 補滿。

總共 255 個序號，每次傳遞 7 個位元組，總共最多傳遞 1785 個位元組的數據。

TPCM.RTS

RTS 訊息通知網絡上的某個特定節點，希望與其建立虛擬連接。RTS 訊息的 SA 會設置為發送端的地址，DA 會設置為訊息的預期接收端地址，傳遞資料內容則為訊息長度、或是所請求的 PGN 編號。

TPCM.CTS

用來回應 RTS 的訊息。CTS 訊息會通知發送端已經準備好接收一定數量的資料。

TPCM.EoM_ACK

由接收端回傳給發送端，表示整個訊息正確並在接收端重組。

TPCM.ConnAbort

可由發送或接收端進行發送，用於未完成訊息傳輸的情況下關閉連接或防止連接初始化。在封包裡面帶有中斷原因。

TPCM.BAM

BAM 不指定目標地址，故目標地址為 0xFF，對網路中的所有節點進行廣播。其特點在於不需要 ACK 確認，簡化了訊息的傳遞流程。

目標地址須為 0xFF (255)，表示為全域廣播。

封包傳遞分析

透過雙通道 CAN，可以實現自發自收。這邊只討論 DP 為 0 的情況，但要知道 DP 可以為 1 表示為擴展 PGN。

單幀訊息傳遞（single-frame）

傳遞的資料內容，其長度 ≤ 8 個位元組。PGN 為 0xEF00 可以實現點對點或是全域廣播。或是 PGN 為 0xFF00 到 0xFFFF 實現全域廣播。

封包傳遞內容如下：

這邊在驗證上發現即使指定目標位置(DA)，如果資料長度 ≤ 8 個位元組，則接收端還是會解此封包，不確定是 PCAN 實作上的差異。然而，長度若超過 8 個位元組，由於 DA 不一致所以接收端不會處理該封包。

多幀訊息傳遞（multi-packet）

傳遞的資料內容，其長度大於 8 個位元組。又可分為廣播與點對點。

針對 BAM，對全域進行廣播傳遞。其封包傳遞內容如下，假設傳遞 15 個位元組：

1. BAM

   BAM 傳遞間隔為 10 ms 到 200 ms [*]，接收端的封包時間差最多為 750 ms。若超過此時間差並預期還有更多封包但未收到，則視為超時並自動關閉連接。

   

從表格中得知，控制值為 0x20，表示為 BAM，數據長度為 0x000F，即 15 個位元組，封包數量為 0x03。後續的 TPDT 封包首位元為序號，後面帶有實際數據。若最後一個封包的數據不足 7 的倍數，則補上 0xFF。

• 由 SAE J1939-21 所定義 BAM 發送後，需等待至少 10 ms 的間隔而非 50 ms，網路上訪問都寫 50 ms，PCAN 的實作也是隔了 50 ms，可能是標準已經更新。這點沒有深入詳細探討。依照官方最新的標準，發送延遲應為 10 ms 至 200 ms，接收端最長的間隔為 750 ms。

2. P2P

   進行 P2P 傳遞資料之前，需要先聲明位置。若未事先聲明，會導致資料無法正常傳送，並可能因資料未正常送達而需要重新發送，造成網路負荷增加及延遲。

   

表格中首先進行握手：RTS (0x10) 封包發送給目標位置 247，247 回傳 CTS 封包，表明可接收封包數量為 0x03，並指定下一個封包的序號為 0x01。之後開始傳遞資料，完成後由 247 發送 ACK 封包，確認收到的數據長度和封包數量。

如果數據長度或接收間隔時間太長（超過 750 ms），會導致接收方發送超時（Timeout）訊息，並要求重新傳輸數據。此時，接收方會傳送 TPCM.CTS 給發送端，請求特定序列號的封包以防止會話中止。

此外，如果發送端速度太慢，可能導致在 TP.DT 傳送過程中，由於接收端超時而發送 TPCM.CTS 要求重傳，並且被發送端接收到。此時，由於會話已經建立，會造成會話中斷（原因：Multi_CTS）。所以，為了避免會話中斷，發送端應確保在超時之前（750 ms）完成數據傳送。如果發送端能在接收到重傳 CTS 之前完成所有數據封包的傳送，會話將能繼續進行而不會中斷。

3. RTS 失敗

當 RTS 傳輸失敗時，系統會依序進行多次重傳，每次重傳間隔約為 50 ms。如果在 1300 ms 內仍未收到回應，則發送 TPCM.ConnAbort 封包以中止連接，然後再次嘗試 RTS 傳輸。這個過程持續重複直到成功或達到最大 3 次重傳次數。

結論

本文深入探討了 SAE J1939 的主要特點與機制，包括在傳輸長度超過或未超過 8 個位元組時的處理方法。通過了解 SAE J1939 的協定，後續才能更進一步掌握 CANopen、AUTOSAR、NMEA 2000 等延伸協定的運作原理。

本文尚未涵蓋 J1939 的全部內容，例如網路管理（network management）、位置宣告（address claiming）、診斷（diagnostics）等議題。這些部分將在後續學習中有機會的話再進行探討。目前提供的資訊應該已足夠幫助理解和應用 J1939 協定的基本概念與操作方法。

更進階的議題可能涉及韌體實作及現有程式碼的整合，例如已經有人實作 Open-SAE-J1939，要如何將其整合進行應用會是比較實際的挑戰。

參考文獻

1. Lawrenz, Wolfhard, ed. CAN System Engineering: From Theory to Practical Applications. Springer, 2013.
2. Vector. “SAE J1939 Know-how”
3. Kvaser. “Higher Layer Protocols”
4. ISO. ISO 15765-3: Road vehicles — Diagnostic communication over Controller Area Network (DoCAN) — Part 3: Implementation of unified diagnostic services (UDS on CAN). ISO, 2004.
5. SAE International. J1939-21-2022: Data Link Layer. SAE, 2022.
6. SAE International. J1939-71-2022: Vehicle Application Layer. SAE, 2022.
7. Wilfried Voss. A Comprehensible Guide to J1939. Copperhill Technologies Corporation, 2008.
8. Daily, J. (2022). Introduction to SAE J1939: A primer for in-vehicle networking.