车载诊断标准ISO157653中文.docx
《车载诊断标准ISO157653中文.docx》由会员分享，可在线阅读，更多相关《车载诊断标准ISO157653中文.docx（63页珍藏版）》请在冰点文库上搜索。
车载诊断标准ISO157653中文
ISO15765-3（2004）
道路车辆——控制局域网络诊断—-
第3部分：
一元化诊断服务实施（CAN的UDS）
道路车辆——控制器局域网（CAN）的诊断——
第3部分：
一元化诊断服务实施（CAN的UDS）
1范围
这部分ISO15765协议按照ISO14229—1，描述了在ISO11898定义的控制器局域网中统一诊断服务（UDS）的实施.它给所有汽车连接至CAN网络服务器及外部测试设备提供诊断服务及服务器存储器编程的需求。
它对汽车内部CAN总线架构无任何要求.
2参考的标准
下述的参考文档对于该文档的应用是必不可少的。
3术语，定义和缩略词
为编撰该文档目的，这些术语和定义已在ISO14229—1,ISO15765-1及ISO15765—2中给出，以下缩略词术语同样适用。
DA目标地址
ID标识符
DLC数据长度码
GW网关
LSB最低有效位
MSB最高有效位
NA网络地址
SA源地址
SM子网掩码
TOS服务类型
4协定
该部分ISO15765协议基于ISO14229-1的协定，该协议遵从使用到诊断服务的OSI服务协议。
5统一诊断服务（UDS）对照OSI模型的应用
见图1
6应用层及会话层
6.1应用层服务
该部分ISO15765协议使用ISO14229—1的客户机—服务器式的应用层服务.该系统具有测试、检测、监视，诊断及汽车服务器在线编程的功能.
6.2应用层协议
该部分ISO15765协议使用ISO14229—1应用层协议。
6.3应用层诊断会话管理定时
重要——任何一个服务器端产生的不等于N_OK的N_USData。
indication的指示服务，服务器应用层都不应该有一个应答信息.
6。
3.1概况
下述的是应用层及会话层的定时参数及它们如何在客户机—服务器模式中如何处理的.
图1OSI模型中,基于CAN的UDS实施
下述的几种通信会话方式需区别开:
a）物理的通信在如下期间
1）默认会话方式
2）非默认的会话方式——需进行会话处理
b）功能的通信在如下期间
1）默认的会话方式
2）非默认的会话方式—-需进行会话处理
所有的情况下，请求服务器否定应答信息的扩展的定时应答，包括应答码78hex应当予以考虑.
定义在ISO15765-2的网络层主要是处理客户机-服务器的应用层及诊断会话管理的定时.
6.3。
2应用层定时参数定义
用于默认的诊断会话的应用层定时参数值应按照如下表2设置
表2——默认会话的应用层定时参数定义
定时参数
描述
类型
最小值
最大值
成功发送请求信息（通过N_USData.con应答指示）到接收答复信息开始（多帧信息的N_USDataFirstFrame。
ind和单帧信息的N_USData。
ind）的超时设置
定时器
重载值
接收到应答码为0x78的否定应答（通过N_USData.con指示）到接收答复信息开始（多帧信息的N_USDataFirstFrame。
ind和单帧信息的N_USData.ind）的扩展的超时设置
定时器
重载值
在接收到请求信息（通过N_USData。
ind指示），服务器开始答复信息的运行要求
运行
要求
0
50ms
在传递了0x78（扩展的超时设置）的否定应答码（通过N_USData。
con指示），服务器开始答复信息的运行要求
运行
要求
5000ms
客户机成功发送不需应答的物理地址请求信息（通过N_USData.con指示），到它能发送下一个物理地址请求信息等待的最小时间（见图6.3.5。
3）
定时器
重载值
客户机成功发送功能地址请求信息（通过N_USData。
con指示）,到它能发送下一个功能地址请求信息等待的最小时间，有可能不需应答也有可能该请求数据只被某个子网功能地址服务器支持（见图6.3。
5.3）
定时器
重载值
a客户机等待一个应答信息发送的最长时间由客户机决定，但必须满足必须比指定的最小值要大；
b值由客户机决定，但必须满足该值必须比指定的最小值要大;
c扩展的应答定时，在连续的应答码为0x78的否定应答信息之间最小值为，最大容差为±20％的；
d客户机发送下一个请求的最长等待时间由客户机决定,但必须满足非默认会话的定时在服务器一直保持运行.
参数被认为是所有系统网络设计参考延时，该延时通过网关及总线带宽加上安全系数（例如最坏情况的50％）。
最坏情况（客户机-服务器—客户机信息传输一个来回的必须得传送时间）,基于系统的设计，并受以下因素的影响：
a）包含网关的数量
b）CAN帧发送的时间（波特率）
c）CAN总线的使用情况
d）CAN设备驱动使用方法（轮询方式还是中断方式）及网络层的处理时间
分为两个时间，一是客户机发送请求至服务器的时间，一是服务器发送应答至客户机的时间。
图2展示的是组成的一个例子.
图2——组成的一个例子—-单帧请求和应答信息
注意：
为了简单描述定时参数，在以下所有的图中,假定客户机到服务器在同一个网络中。
所有的说明及附图按照时间顺序表述。
6.3。
3会话层定时参数定义
当诊断会话而不是默认的会话启动的时，需要按如下表3的会话层定时参数进行会话的操作。
表3-—会话层定时参数定义
定时参数
说明
类型
推荐超时ms
超时ms
在功能地址（0x3E）由客户机发送的用于保持诊断会话的信息请求之间的时间，而不是多服务器的默认会话时间（功能的通信），或者对某一具体服务器发送请求最大时间间隔.（物理的通信）。
时间重置值
2000ms
4000ms
在没有接收到任何请求信息时，服务器保持诊断会话的时间，不是默认会话活动时间。
时间重置值
N/A
5000ms
而且，服务器转变到非默认会话时，应当改变它的应用层定时参数和,以完成适用于诊断会话的操作。
非默认的诊断会话适用的定时参数在诊断会话控制应答信息中报告，当一个应答需要传递（见图9。
2.1服务说明）或需要提前通知客户不传递任何应答信息时。
当客户机启动功能的非默认会话时，它应当调整响应的服务器的定时参数。
表4定义了客户机和服务器开启/重启的/定时条件。
对于客户机,周期性发送功能地址（0x3E）请求信息，应当与连续地发送物理地址（0x3E）请求信息区别开，后者仅仅在没有其它任何诊断请求时发送。
对于服务器，不需要这两种（0x3E）的操作方式。
表4说明定时器操作是基于网络层服务的,也就是说，定时器在接收到不支持的诊断请求信息时，重启。
6。
3。
4客户机和服务器定时器资源要求
对于客户机及服务器在默认会话及任何非默认会话完成上述时间定时的定时器资源要求应按照表5及6所示。
在非默认会话期间，表6所示附加的定时器资源要求适用于客户机及服务器。
表4-—客户机及服务器的会话层定时启动/停止条件
定时
参数
动作
物理和功能通信,
使用功能地址，
周期性发送请求信息
物理通信,
使用功能地址，
连续发送请求信息
初始化
开始
N_USData。
con用于指示诊断会话控制（10hex）请求信息的完成。
只适用于非默认会话的会话类型。
若不需应答，N_USData。
con指示诊断会话控制（10hex）请求信息的完成。
若需一个应答，N_USData.ind指示诊断会话控制（10hex）请求信息的完成。
随后的
开始
N_USData。
con指示功能地址（0x3E）请求信息的完成，它是在定时每次到时时发送.
若不需应答,N_USData。
con指示诊断会话控制任何请求信息的完成。
若需一个应答，N_USData.ind指示诊断会话控制任何请求信息的完成。
N_USData。
ind在接收到多帧应答信息时，指示出错。
初始化
开始
如果需要一条应答信息被传送的话，N_USData。
con指示诊断会话控制应答信息的完成,表示从默认会话转变为非默认会话。
如果不需应答.成功地完成请求的服务,该请求为诊断会话控制（10hex）请求信息要求从默认会话转变至非默认会话,
随后的
结束
N_USDataFirstFrame.ind指示多帧请求信息开始,N_USData。
ind表示任何一个单帧请求信息的接收。
如果使用默认会话,被禁用。
随后的
开始
如果需要一条应答信息被传送的话（包括肯定及否定应答），N_USData.con指示任何应答信息的完成，确定一条服务的执行（最后回复信息）.否定应答应答码0x78不会重启。
如果不需要任何应答信息（肯定或否定）,请求动作的完成（服务结束）
N_USData.ind指示接收多帧请求信息时的出错.
当请求发送未被请求的信息，如基于某一事件的周期性数据及应答，见6.3。
5.4服务器关于更多的处理。
表5——默认会话下定时器资源要求
定时参数
客户机
服务器
为每一个逻辑通信通道（物理和功能通信）设置一个单独的定时器是需要的，例如，点对点通信需要一个独立的通信通道。
N/A
N/A
为扩展的应答定时一个可选择的定时器保证随后的否定应答的发送比早一些。
需为每一个物理通信口提供单独的定时器
N/A
需为每一个功能通信口提供单独的定时器
N/A
表6-—非默认会话下另外的定时资源需求
定时参数
客户机
服务器
当使用周期性发送,功能地址（0x3E）请求信息保持服务器在非默认状态，需提供单独的定时器，不需为每一个激活的诊断会话提供额外的定时器。
N/A
当在无其它诊断请求时,使用连续的发送物理地址（0x3E）请求信息保持单个服务器在非默认状态,为每一个点对点通信通道设置单独的定时器
N/A
服务器需一个单独的定时器，因为只有单诊断会话能在一个服务器中激活.
6.3.5具体的定时参数描述
6.3.5。
1物理通信
6.3.5.1.1默认会话下物理通信
图3描述了客户机和服务器在默认会话下物理地址请求信息定时的操作。
图3——默认会话下物理通信
a）客户端诊断应用层通过发送N_USData.req到网络层开始发送请求信息。
网络层传递该请求信息至服务器。
该请求信息要么以单诊的形式或多帧的形式.
b）在多帧信息情况下，请求开始于网络层发送的N_USDataFF。
ind通知服务器.
c）请求信息的完成通过客户机N_USData.con指示.当接收到N_USData.con时，客户端使用默认重载值为，启动定时器，该定时器的值应当考虑到车载网络设计上（通信网关，总线带宽，等）所有的延时。
为了简单化,该图假定客户机和服务器在一条总线上.
d）服务器通过N_USData。
ind指示请求信息的完成。
e）服务器在接收到N_USData.ind指示时,要求在时间内开始回复信息.也就是说,在多帧回复信息条件下，首帧必须在时间内发送，对于单帧回复信息，该单帧必须在时间内回复。
f）在多帧应答信息情况下，客户机通过网络层N_USDataFF.ind指示首帧的接收。
当接收到首帧时，客户机停止定时器。
g）如果完整的信息接收到,或者在接收过程中出现了错误,网络层最后都产生一个N_USData。
ind。
在单帧响应信息，通过单个的N_USData。
ind指示单帧的接收。
当接收该单帧指示时，客户端停止定时器.
h）服务器通过N_USData。
con指示响应信息的完成。
6.3。
5。
1。
2默认会话期间扩展了应答定时的物理通信
图4描述了默认会话期间客户机和服务器物理地址请求信息定时操作，及服务器请求扩展的响应定时（否定应答码0x78的处理）。
图4——默认会话期间的物理通信-—扩展了应答定时
a）客户端诊断应用层通过发送N_USData.req到网络层开始发送请求信息。
网络层传递该请求信息至服务器。
该请求信息要么以单诊的形式或多帧的形式。
b）在多帧信息情况下，请求开始于网络层发送的N_USDataFF。
ind通知服务器。
c）请求信息的完成通过客户机N_USData。
con指示.当接收到N_USData.con时，客户端使用默认重载值为，启动定时器，该定时器的值应当考虑到车载网络设计上（通信网关，总线带宽,等）所有的岩石。
为了简单化，该图假定客户机和服务器在一条总线上。
d）服务器通过N_USData.ind指示请求信息的完成。
e）服务器在接收到N_USData.ind指示时,要求在时间内开始回复信息.也就是说，在多帧回复信息条件下，首帧必须在时间内发送,对于单帧回复信息，该单帧必须在时间内回复。
f）服务器在给定的时间内无法提供请求的信息时，它可以通过发送应答码为0x78的否定应答信息请求扩展的定时窗.客户端接收到否定应答信息时，客户端网络层产生一个N_USData。
ind。
接收到应答码为0x78的否定应答信息,客户端重置它的定时器,但使用的是扩展的重载的定时值。
g）服务器在发送否定应答信息N_USData.con之后，要求在给定的扩展的（）时间内应答信息。
如果在给定的扩展的时间内仍无法提供请求的信息，服务器则继续发送应答码为0x78的否定应答。
客户端使用的是扩展的重载的定时值重置它的定时器。
为了简单起见，图中只显示了一个应答码为0x78的否定应答信息。
h）一旦服务器可以提供请求的信息（肯定的否定的应答，而不是应答码0x78的应答），它就启动最后结果的应答信息。
i）在多帧应答信息情况下,客户机通过网络层N_USDataFF。
ind指示首帧的接收。
当接收到首帧时，客户机停止定时器。
j）如果完整的信息接收到，或者在接收过程中出现了错误，网络层最后都产生一个N_USData。
ind.在单帧响应信息,通过单个的N_USData.ind指示单帧的接收。
当接收该单帧指示时,客户端停止定时器。
k）服务器通过N_USData。
con指示响应信息的完成。
6.3。
5。
1。
3非默认会话期间的物理通信
6.3。
5.1.3.1功能地址（0x3E）信息
图5——非默认会话期间的物理通信-—功能地址
图5描述了客户机和服务器非默认会话期间物理通信及使用功能地址的定时处理。
客户机周期性发送（0x3E）请求信息,不需要服务器的应答信息。
与定时处理与6.3。
5.1。
1和6.3。
5.1。
2小节中描述的处理方法相同。
唯一的区别是客户端重置的值及服务器端发送结果应答时间会有不同。
这是由于转变到另一会话层而不是使用默认会话层,因此使用的是不同的的值.（见9。
2.1节诊断会话控制（0x10）服务对定时参数更详细的描述。
）
a）客户端诊断应用层通过发送N_USData。
req至网络层，传递诊断会话控制（0x10）请求信息。
网络层传递该请求信息至服务器。
b）请求信息是单帧信息。
它的完成通过客户端N_USData。
con指示.6。
3。
5.1.1和6.3.5.1.2描述的应答定时适用于此。
客户端产生的N_USData。
con促使定时器开启（会话定时器）。
c）服务器通过N_USData。
ind的发送器一个应答。
服务器应当发送诊断会话控制（0x10）的肯定应答信息。
d）服务器通过N_USData。
con指示应答信息发送的完成。
然后服务器开启定时器，只要它不超时，它就一直处于非默认状态.客户机负责保证定时器在它超时之前复位，以保证服务器处于非默认会话状态.
e）一旦客户机开启了定时器，这会促使不需应答信息的功能地址（0x3E）请求信息的发送。
每一次发送的时机都是在超时时发送.
f）在网络层通过N_USData。
con指示（0x3E）请求信息传递完成之后，客户机再次启动定时器。
这就是说，功能地址请求信息是在每一次定时超时之后，周期性发送的。
g）服务器在处理诊断服务的任何时间内，它都停止定时器.
h）当诊断服务处理完之后，服务器重启定时器。
这就是说，诊断服务,包括（0x3E）,都重置定时器。
诊断服务是在接收到请求信息（N_USDataFF。
ind或者N_USData。
ind服务）与完成最后结果应答这个期间内处理的.这里是需要一条应答信息的。
或者请求然后诊断服务动作的完成不需要任何应答信息。
（及时到达一个点会促使一个应答信息的发送）
i）所有（0x3E）请求信息，在服务器处理另外一条请求信息期间接收的话,都会被服务器忽略。
因为它已经停止了定时器，并且在服务处理完之后重启。
6。
53.5.1。
3。
2物理地址（0x3E）信息
图6描述了非默认会话期间客户机与服务器物理通信的定时处理。
以及使用物理地址（0x3E）请求信息需要服务器返回应答信息以保持在没有其它诊断服务的时候诊断会话的持续。
图6——非默认会话期间的物理通信——物理地址
a）客户端诊断应用层通过发送N_USData。
req至网络层，传递诊断会话控制（0x10）请求信息.网络层传递该请求信息至服务器.
b）请求信息是单帧信息。
它的完成通过客户端N_USData。
con指示。
6.3.5。
1.1和6.3.5。
1。
2描述的应答定时适用于此。
客户端产生的N_USData。
con不会促使定时器开启（会话定时器）.这与使用功能地址不同,使用功能地址会周期性发送（0x3E）信息保持诊断会话一直处于激活状态（见6。
3.5。
3。
1）。
c）服务器通过N_USData.ind指示请求信息的完成。
6。
3。
5.1。
1和6.3。
5。
1.2描述的应答定时适用于此。
d）图上给出，假定客户机需要服务器一个应答。
服务器应当发送诊断会话控制（0x10）的肯定应答信息。
e）服务器通过N_USData。
con指示应答信息发送的完成。
然后服务器开启定时器,只要它不超时，它就一直处于非默认状态。
客户机通过N_USData。
ind指示诊断会话控制（0x10）的接收。
这将促使的开启。
客户机负责保证定时器在它超时之前复位，以保证服务器处于非默认会话状态。
f）客户机任何时候发送一条请求信息至服务器（包括（0x3E）信息）,它都会停止.
g）接收到请求信息的单帧或首帧，服务器都停止定时器。
服务器通过N_USData。
ind标识请求信息的完成.6.3.5.1。
1和6.3.5.1.2描述的应答定时适用于此.
h）客户机通过N_USData.ind指示应答信息的完成，这促使客户机开启，服务器通过N_USData。
con指示应答信息的完成，这促使服务器开启.还有一种客户机不需要应答的情况,客户机接收到网络层N_USData。
con确认标识请求信息发送完时,开启，服务器完成请求的动作时,开启,为简单起见，图中显示的是需要应答的情况。
i）如果客户机在超时之前,没有发送任何诊断请求信息，这促使客户机在超时时，发送一条物理地址（0x3E）请求信息。
j）服务器通过N_USData。
ind指示（0x3E）请求信息的接收。
这促使服务器停止定时器。
6。
3。
5。
1。
1和6。
3。
5。
1。
2描述的应答定时适用于此。
k）客户机通过N_USData.ind指示（0x3E）应答信息的完成，这促使客户机开启，服务器通过N_USData.con指示（0x3E）应答信息的完成,这促使服务器开启。
还有一种客户机不需要应答的情况，客户机接收到网络层N_USData.con（0x3E）标识请求信息发送完时，开启,服务器完成请求的动作时,开启，为简单起见,图中显示的是需要应答的情况。
6.3.5.2功能通信
6.3.5。
2。
1默认会话期间的功能通信
图7描述了默认会话期间,一个客户机与2个服务器功能地址请求信息的定时处理。
从服务器角度看,这与物理地址请求信息的定时处理没什么区别。
但是客户机对定时的处理就与物理通信不同。
图7——默认会话期间的功能通信
a）客户端诊断应用层通过发送N_USData。
req至网络层开始发送功能地址请求信息。
网络层传递该请求信息至服务器。
功能地址请求信息只能是单帧信息。
b）客户机通过N_USData。
con指示请求信息的完成.当接到N_USData。
con时，客户机启动定时器，使用默认的重置值。
该定时器的值应当考虑到车载网络设计上（通信网关，总线带宽，等）所有的延时.为了简单化，该图假定客户机和服务器在一条总线上。
c）服务器通过N_USData.ind指示请求信息的完成.
d）功能地址服务器在接收到N_USData.ind后,要求在时间内发送应答信息。
也就是说，在多帧回复信息条件下，首帧必须在时间内发送，对于单帧回复信息，该单帧必须在时间内回复。
e）在多帧应答信息情况下,客户机通过网络层N_USDataFF.ind指示首帧的接收.当接收到首帧时,客户机停止定时器。
f）当接收到首帧/单帧指示接下来的应答信息，客户端要么知道服务器即将应答或已经应答过了，则停止，要么不是所有服务器应答或它不知道服务器即将应答（客户机等待进一步的应答信息）时，重启。
如果完整信息接收到或者在接收过程中产生了一个错误,网络层产生最后结果N_USData.ind.对多帧信息的最后一个N_USData。
ind不对定时器产生影响.
g）服务器通过N_USData.con指示应答信息发送的完成。
、
6.5.3.2。
2默认会话期间扩展应答定时的功能通信
图8描述了默认会话期间客户机与2个服务器功能地址请求信息的定时操作。
这里一个服务器通过应答码为0x78的否定应答请求一个扩展的应答定时。
从服务器角度看，这与物理地址请求信息的定时处理没什么区别.但是客户机对定时的处理就与物理通信不同。
图8——默认会话期间功能通信——扩展的应答定时
a）客户端诊断应用层通过发送N_USData.req至网络层开始发送功能地址请求信息.网络层传递该请求信息至服务器。
功能地址请求信息只能是单帧信息.
b）客户机通过N_USData.con指示请求信息的完成。
当接到N_USData。
con时,客户机启动定时器,使用默认的重置值。
该定时器的值应当考虑到车载网络设计上（通信网关，总线带宽，等）所有的延时。
为了简单化，该图假定客户机和服务器在一条总线上。
c）服务器通过N_USData。
ind指示请求信息的完成。
d）功能地址服务器在接收到N_USData.ind后，要求在时间内发送应答信息。
也就是说，在多帧回复信息条件下，首帧必须在时间内发送，对于单帧回复信息,该单帧必须在时间内回复。
服务器在给定的时间内无法提供请求的信息时,它可以通过发送应答码为0x78的否定应答信息请求扩展的定时窗.
e）客户端接收到否定应答信息时，客户端网络层产生一个N_USData.ind。
接收到应答码为0x78的否定应答信息，客户端重置它的定时器，但使用的是扩展的重载的定时值。
并且，客户端应当在挂起应答信息列表存储一个服务器标识。
一旦在存储在客户端挂起的服务器开始它最后结果应答信息（肯定或否定应答信息包括应答码为0x78的应答）,它将从挂起应答信息列表中删除。
当无任何应答信息挂起时,客户端重新为使用默认的重载值。
为简单化，图中，显示了从服务器#1的仅一个应答码为0x78的否定应答。
f）只要至少有一个服务器在客户机端挂起时，从任一服务器端任何进一步的应答信息,都会促使定时器使用扩展的值重启（见图9，该图显示了当客户机接收到第二个服务器应答信息开始的情况）。
g）至于物理的通信,服务器请求扩展的应答定时要求在扩展的时间（）内，应答信息。
一旦服务器能提供请求的信息,它就通过发送N_USData.req至网络层开启最后结果应答信息。
如果服务器仍然不能在扩展的时间内提供请求的信息，它将继续发送应答码为0x78的否定应答信息。
这会促使客户机再次重启定时器，使用扩展的重载值。
已经存储在客户端挂起应答信息列表中，服务器端包含应答码为0x
升级会员 