1 PASS-THRU接口概念
近年來，車輛使用可編程存儲技術的情況有所增加，而且預計未來將會繼續。這種技術的使用，增加了能夠在不同的車輛配置中使用單個ECU硬件部署的靈活性，唯一的區別是寫入ECU的軟件和標定程序。在服務環境中重新編程允許現場修改ECU操作系統和重新標定。不同的程序編程功能、多種工具是售后對不同車型的維護的負擔。
美國環境保護署（EPA）和加利福尼亞空氣資源委員會（ARB）一直在致力於車輛制造商為售后提供更大的能力——為尾氣排放相關的ECU提供服務——以最少的硬件方面投資，提供車輛通信支持。
汽車工程師學會（SAE）開發了SAE J2534，提供服務於尾氣排放相關ECU最小設備需求的建議方案。SAE J2534由多個文檔組成：
SAE J2534-1定義了一個包含一組硬件功能和編程API的標准接口，這些API可以用於車輛制造商滿足EPA機構和ARB機構的“OBD服務信息”規定對發尾氣排放ECU編程開發的要求。在2004年及以后的汽車
SAE J2534-1定義了包含硬件和API的基本集，這些API用於車輛制造商以滿足EPA和ARB機構對於“OBD服務信息”對尾氣排放相關ECU編程的規定，對所有2004年以后年型車輛售后維修行業有效。這些API同樣可以用於其他目的。對於一些車型，這些API可以同樣用於2004年以前的尾氣排放相關ECU。
圖1：在與尾氣排放有關的控制模塊的編程過程中使用的各種組件之間的關系，以及每個組件的職責：
| 車輛 |
線纜 |
Pass-Thru 設備 |
線纜 |
車輛編程PC |
||
| 底層驅動 |
API |
應用程序 |
||||
| 車輛制造商確定車輛編程序列和安全訪問你 |
工具供應商定義
Pass-Thru設備間的連接。
車輛端SAE J2534
最大長度5米 |
SAE J2534定義的功能
工具供應商供應硬件
可能在掃描工具中實現 |
工具供應商定義PC到Pass-Thru間的線纜需求。 |
工具供應商提供兼容硬件的設備驅動、安裝包和安裝過程。
例如支持： RS232 USB PCMCIA ETHERNET IEEEE 1934 Bluetooth |
SAE J2534-1 |
車輛供應商開發應用程序界面控制台、車輛軟件和標定選項、開發流程和安全算法。 |
| 車輛 制造商 |
工具供應商 |
SAE J2534 |
車輛 制造商 |
|||
Figure 1 車輛編程概覽
車輛供應商提供可以運行於普通PC上的編程應用軟件，該應用程序必須完全掌握控制器的變成需求，並且掌握編程事件。這包括用戶界面、可下載軟件和標定文件的選擇標准、控制對編程能力的安全訪問機制，以及在車輛中規划每個單獨控制模塊所需的實際編程步驟和順序。如果在編程事件之后必須遵循額外的程序，例如清除診斷故障代碼（DTC）、將零件編號或變碼信息寫入控制模塊、或者運行額外的安裝過程，則汽車制造商也必須在PC應用程序中包含這些步驟。
工具供應商提供SAE j2534-1通道接口，以及與PC和車輛的連接。除了硬件之外，工具供應商還應該提供設備驅動程序軟件，一個Windows安裝/安裝應用程序（將安裝供應商的SAE J2534 DLL和其他必要文件，並更新Windows注冊表）。PC和Pass-Thru設備之間的接口可以是工具供應商選擇的任何技術，包括RS-232、RS-485、USB、以太網，或任何其他當前或未來的技術，包括無線技術。
該API包含一組可由車輛編程應用調用以控制Pass-Thru接口，並控制Pass-Thru設備和車輛間通信的函數。Pass-Thru接口不需要理解消息內容，它允許任何被應用程序和ECU使用的任何消息策略和消息結構體通過。由於消息不能被Pass-Thru所理解，所以消息不能夠控制和操作Pass-Thru接口。例如如果發送到ECU的消息切換至高速傳輸，需要一個特殊的指令通知Pass-Thru設備達到高速狀態。
1.1 電腦配置要求
運行Windows系統的PC機，必須支持32bit或支持模擬32bit，PC必須支持連接Internet，系統提供者必須確定其PC機的最低需求。
1.1.1 32bit與64bit操作系統
較新的64bit系統依然支持32 bit模擬層，使32 bit的DLL文件可以被調用。但如果Pass-Thru設備支持64 bit驅動，64 bit系統也可以提供支持。
1.2 應用軟件需求和假設
應用程序構建於32位環境下，並假設PC可以連接互聯網，即使並非所有應用都需要聯網運行。
應用程序必須保證同時只有一個線程調用Pass-Thru DLL庫，即便是不同的線程也不能。如果多個應用程序的若干線程通過Pass-Thru進行交互，應用程序必須有義務保證這些函數調用不能重疊，即一個函數調用必須發生在上一個函數調用完成之后。即使多個通道已經建立好連接，也只能是一個線程訪問Pass-Thru接口。
應用程序可以使用多個通信協議，但只能受限於一定的組合限制。參閱第6.6節。
應用程序不應對任何j2534-1 API函數的完成時間進行任何假設或施加任何限制。應用程序有義務設置和控制Tester Present（保持在線、保持某服務激活的服務）消息。對於任何協議而言Pass-Thru接口本身都不會處理任何的Tester Present信息。
2 PASS-THRU接口需求
2.1 連接至PC
2.1.1 PC和Pass-Thru之間的接口
Pass-Thru接口制造商應確定PC和Pass-Thru之間的接口，它可以是UART、USB、Ethernet、FireWire、Wireless（例如Bluetooth、802.11、Cellular等）或其他允許Pass-Thru滿足文檔中其他需求（包括時間性需求）的連接。工具制造商還需要包含支持這些連接的驅動程序，以至可以使該接口對於PC應用程序和車輛之間是“透明”的。
2.1.2 從PC端斷開設備連接
PC和Pass-Thru之間的接口斷開時需要檢測以下內容：
- 是否在調用API函數時連接斷開
- 是否在API調用期間，斷開導致了數據和配置丟失
在應用程序調用Pass-Thru-Close並在繼續之前成功調用Pass-Thru-Open之前，應使用返回值ERR_DEVICE_NOT_CONNECTED來報告設備斷開連接。有關更多細節，請參閱第6.11.1節。
2.2 PASS-THRU接口DLL
Pass-Thru 接口DLL：
l 支持“背靠背的”函數調用（指連續調用，並且在連續調用之間沒有間歇）。
l 應沒有窗口提示，寫入到STD OUT，或從STDIN讀入。
l 不要求線程安全。
2.3 配置應用程序
如果需要硬件設備配置，則Pass-Thru制造商應該提供配置程序，用戶可以在其中改設置成功使用該設備所需的不同參數：例如COM端口、以太網址等。此外，若Pass-Thru支持固件刷寫，此特性同樣應包含在配置程序中。Pass-Thru設備制造商應該考慮通過配置程序確定設備是否可用，並在不可用時提示用戶。
2.4 鏈接到車輛
在Pass-Thru和車輛之間的接口應是SAE J1962串行數據通信連接器。Pass-Thru和車輛間線纜最大長度為5m，該接口包含一個支持絕緣橡膠插頭,，它接受標准0.175’’的輔助香蕉插針，用於通過可編程電源和車輛上的車輛連接器進行供電連接。
如果由車輛供電，Pass-Thru接口將：
l 在車輛電壓2.0-18.0 VDC下正常工作。
l 可以工作在車輛電壓高至24.0 VDC的情況下，保持至少10分鍾不損壞設備。
l 可以工作在車輛電壓高至24.0 VDC，並正負極接反的情況下，保持至少10分鍾不損壞設備。
l 通過診斷連接器的電源觸點，不超過SAE J1962中規定的電流。
2.5 通信協議
2.5.1 ISO 9141
如果下列規范和ISO 9141存在沖突，下列規范將覆蓋ISO 9141相對應內容。
l 通過Pass-Thru接口支持的最大下沉電流是100 mA。
l 相對於ISO 7637-1的所有測試的范圍是-1.0到+40.0 V。
l 在5個波特率設置期間，Pass-Thru向一個地址發送之前的缺省空閑周期是300ms。
l 應支持波特率10400（公差±0.05%）
l 應支持波特率10000（公差±0.01%）
l 應支持波特率10000（公差±0.2%）的有4800，9600，9615，9800，10870，11905，12500，13158，13889，14706，15625，19200，和115200。
l 波特率由應用程序設置，不需要考慮Pass-Thru接口，Pass-Thru接口對同步數據不做檢查。
l 除默認無校驗外，支持奇偶校驗（7或8位）總是一個起始位和一個停止位。
l 支持小於或大於ISO 9141中規定的定時器值（參閱圖63）。
l 支持通過Pass-Thru接口禁用自動ISO 9141-2/ISO 14230校驗和驗證，以允許車輛制造商對特定的錯誤進行檢測。
l 如果ISO 9141校驗和通過Pass-Thru接口進行驗證，並且校驗和不正確，則消息將被丟棄。
l 支持PassThruIoctl（…IO控制），它的IOCTL ID等於FAST_INIT和FIVE_BAUD_INIT。
l Pass-Thru接口不應根據Keyword值調整計數器值。
l 在快速初始化和5-波特初始化之間，Pass-Thru接口不應強制執行任何延遲。應用程序的責任是確保這些操作不會干擾車輛的初始化過程。
l Pass-Thru接口應接收和過濾數據鏈路上的所有消息，而無需發送請求。
l Pass-Thru接口應該能處理P1_MIN=0的情況。
l Pass-Thru接口應使用P1_MAX來表示消息的結束。
l 在傳輸請求之后，Pass-Thru接口應該能夠處理立即響應（相當於P2_MIN=0）。如果沒有響應，Pass-Thru接口應在傳輸下一條消息之前等待P2_MAX（當有響應時P3_MIN）。
l Pass-Thru接口不檢查P2_MAX違規。
l Pass-Thru檢查傳輸損壞，但不試圖重發數據。（當傳輸字節與汽車物理總線字節不同時視為傳輸損壞。）
l 對於$78響應代碼，Pass-Thru接口不執行任何特殊處理。任何帶有$78響應代碼的消息都將從Pass-Thru接口傳遞給應用程序。應用程序需要根據收到的響應代碼來處理任何特殊的計時需求，包括停止任何周期性消息。
2.5.2 ISO 14230(KWP 2000)
ISO 14230協議與前一節中概述的ISO 9141協議具有相同的規范。此外，下列規范說明闡述了：如果下列規范與ISO 14230發生沖突，則覆蓋ISO 14230中相關規范：
l Pass-Thru接口應該使用頭長度字段和P1_MAX，出現其一，即決定了消息結束。
2.5.3 SAE J1850 41.6kbps PWM (Pulse Width Modulation)
除了SAE J1850的需求之外，Pass-Thru接口必須支持以下特性：
l 只支持41.6 kbps和83.3 kbps。
l 功能性消息查找表的大小應該是8個地址。
l 除了在“總線+”和“總線-”上進行通信之外，新設計的硬件還應該考慮支持網絡線路選擇（在“總線-”或者“總線+”二者其一上通信的能力）。
2.5.4 SAE J1850 10.4 kbps VPW (Variable Pulse Width)
除了SAE J1850的需求之外，Pass-Thru接口必須支持以下特性：
l 只支持10.4 kbps和41.6 kbps。
l 最多支持4128字節塊傳輸。
l 在物理車輛總線上檢測到中斷信號后，返回到10.4 kbps。
2.5.5 CAN
除了ISO 11898（CAN）的要求外，Pass-Thru接口必須支持以下特性：
l 只支持125000、250000和500000的數據速率。
l 支持11和29位標識符。
l 根據數據速率，在相應的SAE J2284-1（125 kbps）中使用任何CAN控制器設置，SAE J2284-2（250 kbps），或SAE J2284-3（500 kbps）。
l Pass-Thru接口應具有ISO 15765-4:2005所規定的物理層。
2.5.6 ISO 15765 (傳輸層 CAN)
除了ISO 15765的要求外，還必須通過Pass-Thru接口支持以下特性：
l 為了保持可接受的編程時間，Pass-Thru設備必須包含ISO 15765-2定義的傳輸層流控制功能（Flow Control）。如果應用程序不使用ISO 15765-2傳輸層流控制功能，那么CAN協議將允許使用任何傳輸層。
l 接收一個分段的消息，其中有ISO 15765-2所定義的ISO15765_BS=0和一個ISO 15765_STMIN = 0。傳輸一個在流控幀中定義STmin的消息不超過1ms。
l 沒有相應的邏輯通信通道，就不能接收單個幀或分段消息。沒有相應的邏輯通信通道，不能發送分段消息。
l 當數據幀被Pass-Thru接口填充時，填充字節應該是IOCTL配置參數ISO15765_PAD_VALUES定義的，在不修改的情況下，缺省值是$00。
l Pass-Thru接口接收任何ECU的填充值。
l 當檢測到一個填充違規，Pass-Thru接口檢查每個消息的填充位，並設置相關消息的接收狀態節點（即RxStatus element）為ISO15765_PADDING_ERROR （比特）值，
l Pass-Thru應支持以ISO 15765-2定義的——對每條邏輯通道的——全雙工和半雙工通信。對於N_PDU的意外到達，請參閱ISO 15765-2的細節。
l Pass-Thru接口應具有ISO 15765-4:2005所指定的物理層。
2.5.7 SAE J2610 (也稱為 CHRYSLER SCI)
l 只支持7812.5和62500數據
l SCI A和SCI B是相互排斥的，不能同時操作。
當在半雙工模式下傳輸時（當<TxFlags>的SCI_MODE被設置為1）時，每個傳輸的數據字節都將被ECU“echoed”。下一個數據字節將不會被傳輸，直到收到並驗證了echo(應答)字節。如果收到的響應字節與傳輸的字節不匹配，或者在T1_MAX沒有收到響應之后，那么傳輸將被終止。匹配的字節將不會被放置在接收消息隊列中。
當接收來自控制器的消息時，接收到的字節永遠不會被Pass-Thru接口“echo(應答)”。
2.6 多協議同時通信
Pass-Thru接口應在單個編程事件期間支持多協議同時通信，圖2表示應得到支持的協議組合，如果在編程事件期間內不需要支持SAE J2610，Pass-Thru接口能夠和協議鏈路1、協議鏈路2和協議鏈路3同時進行通信。如果在編程事件期間內需要支持SAE J2610，Pass-Thru接口可以在SAE J2610協議和協議鏈路1同時通信。
|
|
數據鏈路集1 |
數據鏈路集2 |
數據鏈路集3 |
| SAE J2610未激活 |
SAE J1850 VPW SAE J1850 PWM |
ISO 9141 ISO 14230 |
CAN (and/or ISO 15765) |
| SAE J2610激活 |
SAE J1850 VPW SAE J1850 PWM |
SCI A（發動機或變速箱） SCI B（發動機或變速箱） |
NONE |
Figure 2多協議同時通信
2.7 可編程電源
Pass-Thru接口應具有可編程電源，需滿足以下要求：
l 最低5 V直流
l 最高20 V直流
l 分辨率0.1 V直流
l 精准度要求在所需電壓上下浮動2%
l 最大電流150 mA
l 最大反向電流300 mA（只對於第15號針腳SHORT_TO_GROUND“接地”）。在SHORT_TO_GROUND的最大電壓輸出為0.5 V直流。做大輸入電壓為20 V直流。
l 最大1 ms穩定時間（只需要SAE J2510通道，關於更多細節的參考SAE J2610信息報告）
l 軟件選擇針腳分配。
l 除SAE J2610通道外，PIN_OFF針腳處設置500,000Ω電阻。（在通道斷開之前，該針腳不會返回信號到該電阻）。
l SHORT_TO_GROUND和可變電壓接地基准為信號地（Signal Ground），定義為J1962連接器第5針腳。
可編程電源應能提供以下所有的針腳（在任何時間內的一根針腳）：
l SAE J1962連接器，第6針腳
l SAE J1962連接器，第9針腳
l SAE J1962連接器，第11針腳
l SAE J1962連接器，第12針腳
l SAE J1962連接器，第13針腳
l SAE J1962連接器，第14針腳
l 一個輔助針腳（香蕉插槽）通過車輛定義的線纜與車輛進行連接（參閱第7.3.16）。
Pass-Thru接口還可以通過SAE J1962的第15針腳短接到地。
2.8 針腳定義
圖3指示了SAE J2534-1每個SAE J1962針腳和輔助針腳。圖3也指示了每個針腳的缺省狀態。當Pass-Thru初始化供電或者當一個針腳不再用於供可編程電源使用，而去供短接地使用或用於串行數據傳輸，這個針腳將被設置為缺省狀態。在圖中，地盤接地電阻被設置為500,000Ω。
| 針腳號 |
用途 |
缺省狀態 |
| Aux |
默認編程電壓（非SAE J1962連接器的一部分） |
高電阻 |
| 1 |
不用於SAE J2534-1 |
高電阻 |
| 2 |
SAE J1850 (+) |
高電阻或SAE J1850 (+)* |
| 3 |
不用於SAE J2534-1 |
高電阻 |
| 4 |
底盤接地 |
底盤接地 |
| 5 |
信號接地 |
信號接地 |
| 6 |
ISO 15765/高速 CAN 可編程電壓 SCI A Engine(Rx) |
高電阻 |
| 7 |
ISO 9141/ ISO 14230 K-Line SCI A Engine (Tx) SCI A Trans (Tx) SCI B Engine (Tx) |
高電阻 |
| 8 |
不用於SAE J2534-1 |
高電阻 |
| 9 |
SCI B Trans (Rx) 可編程電壓 |
高電阻 |
| 10 |
SAE J1850 (-) |
高電阻或SAE J1850 (-)* |
| 11 |
可編程電壓 |
高電阻 |
| 12 |
SCI B Engine (Rx) 可編程電壓 |
高電阻 |
| 13 |
可編程電壓 |
高電阻 |
| 14 |
ISO 15765/ CAN Low 可編程電壓 SCI A Trans (Rx) |
高電阻 |
| 15 |
ISO 9141/ ISO 14230 L-line 對地短接 SCI B Trans (Tx) |
高電阻 |
| 16 |
非開關電池電壓 |
非開關電池電壓 |
* 建議將新的Pass-Thru接口定義缺省為高電阻。
Figure 3 SAE J1962針腳定義
2.9 通信通道
SAE J2534使用“通道”的概念來描述通過傳輸的設備將如何與車輛交互。本節簡要介紹了它們的類型和限制。
通信通道被認為是從Pass-Thru到車輛的路徑。SAE J2534 API為每個路徑分配一個標識，即Protocol ID（協議標識），SAE J2534種定義了兩種通信通道：物理通信通道和邏輯通信通道。
物理通信通道定義一個透過Pass-Thru接口道車輛物理總線的路徑，該路徑包括物理層和數據層（作為OSI七層中的定義）並包含所有的物理資源（數據鏈路控制器、連接器、針腳等）。物理通信通道有自己的接收和發送隊列。常用的物理通信通道例如：SAE J1850 VPW、SAE J1850 PWM、ISO 9141、ISO 14230、SAE J2610和CAN。
邏輯通信通道定義了從Pass-Thru到車輛總線的特定通道，該通道使用現有的物理通信通道，但另添加了網絡層和傳輸層（在OSI七層規范中定義），在SAE 2534-1種定義的唯一的邏輯通信通道是ISO 15765，它覆蓋了CAN物理通信通道並附加包含傳輸機制的附加協議。
一般而言，邏輯通信通道用於兩節點間直接通信。邏輯通信通道擁有自己的發送和接收隊列，可以接收指示信息（例如Start、TxDone或ErrInd）。一個典型的邏輯通信通道示例是使用ISO 15765在J2534設備和車輛發動機控制器之間的通信。ISO 15765流控消息在兩個節點交換，共享它們的信息，用以忽略網絡上其他活動的影響。
每個物理通信信道可以有多達10個邏輯通信通道。在任何給定的邏輯通信信道上寫入的消息將按照它們所寫的順序出現在物理通信通道上。然而，來自邏輯通信通道的消息可能在不違反協議的情況下，與來自其他邏輯通信通道（使用相同物理通信通道）的消息交錯。在物理通信信道上寫入的消息將不考慮任何相關邏輯通信通道的協議。更多詳情請參閱PassThruQueneMsgs。
SAE J2534-1接口接收消息遵循物理通信通道通過Pass-Thru接口返回給應用程序，消息的副本也可以通過Pass-Thru接口返回給應用程序。詳情參閱PassThruReadMsgs。
物理通信通道和邏輯通信通道都可以通過IOCTL SET_CONFIG進行配置，但是其中一些參數只能被物理通信通道設置，而另一些則只能被邏輯通信通道配置。即使基於同一個物理通信通道，配置參數對一個邏輯通信通道進行的設置對其他邏輯通信通道是沒有作用的。詳情參閱PassThruIoctl。
消息過濾器只能在物理通信通道上啟動。每個物理通信通道至多能擁有10個pass/block消息過濾器（對於任何組合）。所有傳入消息都應受到所定義的過濾器的制約。物理通信通道上設置的過濾器對邏輯通信通道沒有影響。詳情參閱PassThruStartMsgFilter。
周期性消息可以在物理通信通道和邏輯通信通道上啟動。詳情參閱PassThruStartPeriodicMsg，以及對周期性消息的制約。
2.10數據緩沖
2.10.1 消息接收
Pass-Thru接口應提供如圖4所示的接收緩沖區，並且能夠接收和緩沖直到接收緩沖區滿了為止。所緩沖的消息數量取決於接收到的消息的大小。這種能力應對於所有支持的波特率環境中有效。（波特率高的情況下，理論上數據填充可能會很快。）
| <ProtocolID> |
每個消息的最大容量 |
接收消息最小緩沖區容量* |
| CAN |
12 Bytes |
4128 Bytes |
| ISO15765 |
4100 Bytes |
各邏輯通信通道4128 Bytes |
| J1850PWM |
11 Bytes |
4128 Bytes |
| J1850VPW |
4128 Bytes |
4128 Bytes |
| ISO9141 |
4128 Bytes |
4128 Bytes |
| ISO14230 |
260 Bytes |
4128 Bytes |
| J2610 |
4128 Bytes |
4128 Bytes |
*Pass-Thru對消息緩沖封頂情況應有額外的存儲策略（例如：時間戳等）
Figure 4最小接收消息緩沖區大小
2.10.2 消息傳輸
在圖5種，Pass-Thru接口應有對單獨寫入操作的排列若干數量字節的能力（由PassThruQueueMsgs填充），緩沖的消息數量取決於所傳輸的消息的大小。
| <ProtocolID> |
每個消息的最大容量 |
單獨的寫操作最小發送隊列容量* |
| CAN |
12 Bytes |
4128 Bytes |
| ISO15765 |
4100 Bytes |
各邏輯通信通道4128 Bytes |
| J1850PWM |
11 Bytes |
4128 Bytes |
| J1850VPW |
4128 Bytes |
4128 Bytes |
| ISO9141 |
4128 Bytes |
4128 Bytes |
| ISO14230 |
260 Bytes |
4128 Bytes |
| J2610 |
4128 Bytes |
4128 Bytes |
Pass-Thru接口應該包括額外的存儲消息開銷（例如TxFlags等）。
Figure 5最小傳輸消息緩存容量
除了用於單獨寫的傳輸隊列之外，所有物理和邏輯通信通道都應能夠排隊發送周期性消息（通過PassThruStartPeriodicMsg填充）。不包含邏輯通信通道的物理邏輯通信通能夠排列至多10條消息。關聯邏輯通信通道的物理通信通道必須在所有的通道之間共享者10條消息（也就是說：物理通信通道和其所關聯的邏輯通信通道所有的周期性消息總數不能超過10）。排隊等待傳輸的頂起消息應當優先於排隊等待傳輸的單個消息。一旦一個周期性消息排隊等待傳輸，其相關的時間間隔直到消息傳輸才開始計時，他消除了相同周期信息的多個副本將會“堆疊（stack-up）”的可能性。
所有的物理通信通道具有相同的優先權，並且應當通過循環方式服務於數據傳輸。在更高的層次上來看，這意味着每個通信通道依次具有傳輸的機會。關聯邏輯通信通道的物理通信通道將以循環方式服務於這些邏輯通信通道。如果下一個通信通道沒有要傳輸的內容或者在當時不允許傳輸（被物理或協議層阻止），那么接下來的一個通信通道將獲得傳輸的機會。這並不意味着必須先結束本次傳輸，然后下一個通道才可以服務，多個物理通信通道預計將同時通信，多個邏輯通道在底層協議允許的情況下也預計將同時通信。
| <ProtocolID> |
傳輸退讓點(Yield Point) |
| ISO15765 |
CAN Frame |
Figure 6邏輯通信通道的傳輸屈服點
圖7是對傳輸過程中涉及的各種操作的概念概述。它的目的是幫助總結消息傳輸的概念（它並不是要指定一個具體的實現）。
Figure 7發送過程概述
在這個概述中，物理和邏輯通信通道傳輸管理的屬性是：
l 實現循環策略，以確保沒有通信通道被“餓死”。
l 為一個或多個邏輯通信通道，對物理通信通道應用一個第二級循環策略。
l 確定所選的物理/邏輯通信通道是否有消息要傳遞。
物理和邏輯通信信道的屬性是：
l 實現網絡和傳輸層（在適用的情況下）。
l 通過PassThruStartPeriodicMsg()維護自己的消息傳輸請求隊列，該隊列比通過PassThruQueueMsgs()傳輸請求的消息傳輸請求優先級更高。
l 通過PassThruQueueMsgs維護自己的消息傳輸請求隊列。
l 當有機會傳輸時提供下一個消息幀。
低級數據鏈接驅動程序的屬性是：
l 對單個協議幀進行操作（例如CAN幀）。
l 異步操作，獨立於應用程序與物理/邏輯通信通道的交互。
l 以FIFO（先進先出隊列）的方式操作傳輸隊列。
l 當總線處於就緒或空閑時，它在傳輸隊列中檢索下一個協議幀，並開始傳輸。
l 例如按圖8描述的三個物理通道：ISO 9141，SAE J1850 PWM，CAN和三個使用物理通信通道的：ISO 15765#1，ISO 15765#2，ISO 15765#3。
Figure 8循環消息傳輸示例的通信通道配置
Figure 9循環消息傳輸服務順序示例
假設當一個消息轉到底層通道傳輸例程，傳輸將在后台進行，並且該傳輸持續服務於傳輸隊列。 消息持續被底層通道傳輸例程，直到整個消息傳輸完成。然而，當一個物理傳輸通道關聯若干邏輯傳輸通道，所有關聯的（邏輯）通道必須以循環方式共享對物理層的訪問。既然如此，在圖6種列舉了，協議中規定哪個通道應該退讓（Yield）。
假設我們繼續上面的例子，假設每個ISO 15765通道在隊列中至少有一個分段消息（Segmented Message）傳輸，並且CAN通道在隊列中有許多可用於傳輸的幀；然后圖10顯示了消息交錯如何在CAN物理層上查看。
|
Oldest |
|
Newest |
|
TIME |
|
CAN, Frame 1 ISO 15765 #1, Message Frame 1 ISO 15765 #2, Message Frame 1 ISO 15765 #3, Message Frame 1 CAN, Frame 2 ISO 15765 #1, Message Frame 2 ISO 15765 #2, Message Frame 2 ISO 15765 #3, Message Frame 2
CAN, Frame n ISO 15765 #1, Message Frame n ISO 15765 #2, Message Frame n ISO 15765 #3, Message Frame n
.
.
. |
Figure 10在物理層上的消息交錯
2.11錯誤處理
2.11.1 設備未連接
返回值ERR_DEVICE_NOT_CONNECTED表明Pass-Thru接口DLL在某一時刻未能與Pass-Thru設備通信——盡管它目前可能還沒有斷開連接。
2.11.1.1 Pass-Thru設備
當檢測到ERR_DEVICE_NOT_CONNECTED錯誤時，所有后續的函數調用（帶有PassThruGetLastError，PassThruScanForDevices，和PassThruGetNextDevice這些異常的）都應返回ERR_DEVICE_NOT_CONNECTED，該設備將像PassThruClose被調用一樣。（這個假設是沒有其他優先級高的返回值可用，更多關於返回值的優先級的詳細信息參閱7.1節。）
2.11.1.2 應用程序
當一個函數返回值ERR_DEVICE_NOT_CONNECTED時，應用程序必須與Pass-Thru設備重新建立通信。要做到這一點，應用程序應該調用PassThruClose（它可能返回一個錯誤代碼），然后在繼續之前成功地調用PassThruOpen。
2.11.2 接收緩沖區溢出
接受緩沖溢出可能發生在Pass-Thru的任何地方（例如在數據鏈路控制器、設備接收緩沖區、DLL接收緩沖區等等）。當接收緩沖區溢出條件發生時，Pass-Thru接口應：
l 丟棄溢出條件之前的任何部分消息
l 在溢出條件清除之前，完全丟棄新消息。
l 在溢出條件清除之前丟棄新的指示。（丟棄指示不得改變正常的傳輸過程。）
l 在ISO 15765接收分段消息期間，Pass-Thru接口傳輸流控響應信息中包含的FlowStatus（流狀態）應當指示ISO 15765所述的溢出條件。
在溢出條件清除后，對於第一個成功接受的消息，在PASSTHRU_MSG結構的<RxStatus>設置BUFFER_OVERFLOW位（bit），將用於把丟失的消息/指示傳遞給應用程序。
2.11.3 消息傳輸
除另具說明外，當中止一個傳輸，活動的消息將在下一個中止邊界處停止（，邊界是指最小消息單元，例如CAN幀，UART字節等）。並且將在傳輸隊列中丟棄相關消息。（例如，在ISO 15765邏輯通信通道中，Pass-Thru接口不處理任何接下來的連續幀，直到接下來的首幀或單幀已經被接收或發布。）
除另具說明外，在終止傳輸時，應在下一個終止邊界停止活動消息（，邊界是指最小消息單元，例如CAN幀，UART字節等。）並且相關的消息會在傳輸隊列中被刪除。任何已經被控制器加載的傳輸部分，在中止行為發生時，將會繼續被執行，直到完成。（例如，在ISO 15765邏輯通信通道中，Pass-Thru接口不處理任何接下來的連續幀，直到接下來的首幀或單幀已經被接收或發布。）如果關聯的消息請求TxDone指示，則會生成TxFailed指示。任何接下來的傳輸消息將遵循協議規范。圖11列舉了各協議中的消息中止邊界。
| <ProtocolID> |
Termination Boundary |
| CAN |
CAN Frame |
| ISO15765 |
CAN Frame |
| J1850PWM |
J1850 Frame |
| ISO14230 |
Byte |
| ISO9141 |
Byte |
| J1850VPW |
Byte |
| J2610 |
J2610 Byte |
Figure 11消息中止邊界
2.11.4 網絡錯誤
Pass-Thru接口應當能夠檢測出發送和接收的錯誤。針對各種錯誤的處理，在SAE J2534-1中定義了恢復策略（Recovery Strategy）。圖12詳細說明了要檢測到的錯誤的類型，和相應的恢復策略，以及在指定恢復策略結束后應發生的應用程序提示機制（Application Notification Mechanism）；應用程序提示機制在第6.11.4.1和6.11.4.4兩節中進行了詳細說明。
| <ProtocolID> |
錯誤 |
應用程序提示機制 |
恢復策略 |
| CAN |
未告知已收或仲裁失利 |
NONE或TxFailed標識 (如果請求了TxDone) |
控制器重試策略 (Controller Retry Strategy) |
| 總線警告 |
NONE |
控制器重試策略 |
|
| 超速錯誤 |
在<RxStatus>中設置 BUFFER_OVERFLOW |
NONE （消息已經丟失） |
|
| 在消息接收期間的： Form error, Stuff error, CRC error, Bit 0 error, Bit 1 error |
NONE |
NONE |
|
| 消息傳送期間的： Form error, Stuff error, CRC error, Bit 0 error, Bit 1 error |
NONE或TxFailed指示 (如果請求了TxDone) |
控制器重試策略 |
|
| 總線關閉 |
生成LINK_DOWN ErrInd指示 |
被動操作策略 (Passive Operation Strategy) |
|
| ISO15765 |
未告知已收或仲裁失利 |
NONE或TxFailed標識 (如果請求了TxDone) |
控制器重試策略 |
| 總線警告 |
NONE |
控制器重試策略 |
|
| 超速錯誤 |
在<RxStatus>中設置 BUFFER_OVERFLOW |
放棄策略 |
|
| 消息接收期間的： Form error, Stuff error, CRC error, Bit 0 error, Bit 1 error, 或者ISO 15765中定義的錯誤： (N_TIMEOUT_A, N_ERROR, N_TIMEOUT_CR, N_WRONG_SN, or N_UNEXP_PDU) |
NONE |
NONE |
|
| 在消息傳送期間的： Form error, Stuff error, CRC error, Bit 0 error, Bit 1 error |
NONE或TxFailed標識 (如果請求了TxDone) |
控制器重試策略 |
|
| 在消息傳輸期間，在ISO 15765中定義的錯誤： (N_TIMEOUT_A, N_BUFFER_OVERFLW, N_TIMEOUT_BS, N_INVALID_FS, or N_ERROR), 或者超出ISO15765_WAIT_LIMIT 限制。 (PassThruIoctl中設置)
|
NONE或TxFailed標識 (如果請求了TxDone) |
放棄策略 |
|
| 總線關閉 |
生成LINK_DOWN ErrInd指示 |
被動操作策略 |
|
| J1850PWM |
未告知已收或仲裁失利 |
NONE或TxFailed標識 (如果請求了TxDone) |
控制器重試策略 |
| 總線故障 |
NONE |
控制器重試策略 |
|
| 接收超速 |
在<RxStatus>中設置 BUFFER_OVERFLOW |
放棄策略 |
|
| 接收錯誤、CRC錯誤、無法告知已收、網絡錯誤 |
NONE |
放棄策略 |
|
| J1850VPW |
仲裁失利或網絡錯誤 （傳送錯誤縱線短路故障?bus short error） |
NONE或TxFailed標識 (如果請求了TxDone) |
控制器重試策略 |
| 超速錯誤 |
在<RxStatus>中設置 BUFFER_OVERFLOW |
放棄策略 |
|
| CRC錯誤或網絡故障 （Symbol error, Framing error, or Bit timing） |
NONE |
放棄策略 |
|
| 跳出 |
生成Break標識 |
不適用 |
|
| ISO9141 |
接收超速URAT錯誤 |
在<RxStatus>中設置 BUFFER_OVERFLOW |
放棄策略 |
| 消息接收期間： 所有的UART錯誤（除接收超速外），或無效的校驗值 |
NONE |
放棄策略 |
|
| 在消息傳送期間： 所有的UART錯誤（除接收超速外），接受位不匹配，或收發器檢查到故障 |
NONE或TxFailed標識 (如果請求了TxDone) |
放棄策略 |
|
| ISO14230 |
接收超速URAT錯誤 |
在<RxStatus>中設置 BUFFER_OVERFLOW |
放棄策略 |
| 消息接收期間： 所有的UART錯誤（除接收超速外），無效的校驗值（在校驗和可用情況下），長度錯誤，或無效的頭格式位（大小不匹配或無效A0/A1） |
NONE |
放棄策略 |
|
| 在消息傳送期間： 所有的UART錯誤（除接收超速外），接受位不匹配，或者收發器檢查到錯誤。 |
NONE或TxFailed標識 （如果請求了TxDone） |
放棄策略 |
|
| J2610 |
接收超時UART錯誤 |
在<RxStatus>中設置 BUFFER_OVERFLOW |
放棄策略 |
| 消息接收期間： 所有的UART錯誤（除接收超速外） |
NONE |
放棄策略 |
|
| 消息傳送期間：輸出位不匹配(SCI_MODE=1且正在傳送一個消息) |
NONE或TxFailed標識 （如果請求了TxDone） |
放棄策略 |
|
| 跳出 |
生成Break標識 |
不適用 |
Figure 12網絡錯誤
2.11.4.1 控制器重試策略
控制器重試策略在當數據鏈路控制器在無外界介入情況下，自動重試。發生重試是因為仲裁失利，或發生其他控制器在無外界影響的情況下可以處理的事件（通常，這些特性是內置到網絡控制器芯片的）。控制器在遵循協議規范的情況下，可以嘗試發送指定次數或不斷嘗試，直到其成功為止。如果數據鏈路控制器在沒有成功發送數據包的情況下停止重試，那么Pass-Thru接口應該將當前的消息傳輸結果視為不成功，並將其從傳輸隊列中刪除。如果重新嘗試的消息被指定為生成TxDone指示（只有在傳輸成功之后），那么該指示的一個副本將被放置在接收隊列中。在傳輸嘗試停止之后，指定生成TxDone指示的消息的不成功傳輸，將產生單個TxFailed指示。如果數據鏈路控制器不支持重試，則固件/軟件不應重試。
2.11.4.2 接口重試策略
接口重試策略應該繼續嘗試發送消息，直到它成功或相關超時過期和/或在指定的重試次數之后。即使數據鏈路控制器不支持重試，固件/軟件也將繼續重試。如果重新嘗試的消息被指定為生成TxDone指示，那么該指示的一個副本將被放置在接收隊列中，但是只有在傳輸成功之后。指定生成TxDone指示的消息的不成功傳輸，將產生TxFailed指示。
2.11.4.3 放棄策略
放棄策略應立即終止消息，並按照第6.11.3節中指定的內容丟棄它。
2.11.4.4 被動操作策略
當監測到指定的錯誤條件時，Pass-Thru的數據鏈路控制器應開啟被動操作策略。被動操作中的若干通道，應當停止參與消息的傳輸，和可能的消息接收（取決於Pass-Thru接口的功能）。
如果在發送過程中發生上述情況，且在協議計時器超時之前將數據鏈路控制器恢復到運行狀態，將繼續執行最后一次未完成的傳輸。否則Pass-Thru接口將中止在第6.11.3節中指定的所有活動消息。
如果在接收過程中發生上述情況，且在協議計時器超時之前將數據鏈路控制器恢復到運行狀態，將繼續進行接收。否則Pass-Thru接口將中止第6.11.3節中所指定的消息。
應用程序將使用下列任意一種機制，將運行狀態返回到Pass-Thru接口。
- 主動重連——調用PassThruDisconnect緊接着調用PassThruConnect。這將會斷開和重連物理通信通道，重置到默認狀態。這樣就意味着任何對通道的配置、過濾器設置、或開啟周期性消息必須重做。此外對於邏輯通信通道的任何調用連接、配置或開始周期性消息也必須重做。
- 總線開啟命令——用BUS_ON的IOCTL ID和物理通信通道的Channel ID來調用PassThruIoctl，在進入BUS_OFF之前恢復控制器的配置。既然這樣，就不需要在物理通信通道或任何與之關聯的邏輯通信通道上重新連接、重新配置、重設過濾器或重新開始周期性消息。然而，在通道切換到BUS_OFF時任何開始傳輸的消息將會丟失。如果需要，應用程序負責重新發送這些消息。
老版本的SAE J2534-1有規定Pass-Thru接口自動充值CAN控制器，並試圖再次重新發送。現在已經不再采用這樣的策略了，目前采用的是應用程序負責重新建立傳輸。