J2534-1 OCT 2015 Pass-Thru笔记（5-6）
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控制器，并试图再次重新发送。现在已经不再采用这样的策略了，目前采用的是应用程序负责重新建立传输。
