ISO15765的难点和重点（网络层定时参数+应用层定时参数）

简介：ISO15765简介

ISO 15765的中文含义为道路车辆 - 基于CAN网络的诊断通信（DoCAN），整套协议由以下部分组成：

- ISO 15765-1第1部分：一般信息和用例定义（这里都是一些概念）

-ISO 15765-2 第2部分：传输协议和网络层服务

- ISO 15765-3第3部分：统一诊断服务的实施（CAN上的UDS ）

- ISO 15765-4第4部分：与排放有关的系统的要求（排放系统是指与发动机相关，尾气排放相关的规范，因为世界各国环保政策，导致其与一般ECU需要执行的标准不一样）

出现背景

概念1：要系统的了解ISO15765，要结合IEC7498 七层模型，才能更好的了解该协议的内容，做到融会贯通。

诊断应用层（ISO14229）该协议不是专门针对CAN总线设置的。

应用层 IS015765-3

表示层（诊断不涉及该层）

会话层（诊断不涉及该层）（部分文档将会话层描述为IS015765-3描述）

传输层（诊断不涉及该层）

网络层（ISO15765-2）

数据链路层（ISO11898）

物理层（ISO11898）

多说一句，我们传统的CAN总线或LIN总线，大多数实际项目其实只包括（应用层）+数据链路层+物理层。

而诊断，因为数据更加复杂，在架构时，增加了一个传输层。比如19读DTC时，其数据长度可能达到几十个字节（一个DTC占用3个Byte）。就必然要将数据分段传输。ISO 15765-2就是规定了如何传输和将信息分片。

ISO-14229-1是uds统一诊断的规范。

ISO-11898-1/2是数据链路层规范。

不容易理解点，总结一下ISO14229-1和IS015765-3的区别和联系，ISO14229-1,仅定义了数据的格式，如说明了哪些服务，DID等。

1：PDU（protocol Data Unit）简称协议数据单元。

一般情况下，会根据分层不同，加上不同的前缀，网络层PDU=N_PDU

数据链路层=L_PDU

应用层=A_PDU

比如22 F1 94 读软件版本号 。

应用层数据单元只包含：

1:（22）=(服务名称)+（DID数据）

2：网络层：会添加寻址信息Address（就是地址），寻址方式(功能寻址+物理寻址)，将信息分片:

3：数据链路层：会将添加数据长度信息（DLC）,添加校验，添加仲裁方式（如：CSMA/CD(载波监听多路访问/冲突检测)原理），添加CRC校验，添加sof ，和帧结尾等信息。都是数据链路层，添加的信息。

数据链路层;基本实现方法，都是封装在底层代码中，一般情况下，我们只需要对协议栈进行配置即可，实现功能的定制化。

但是据我自己的项目经验：目前不是所有的芯片，都支持，网络层的协议栈配置，有些低端芯片还需要程序员去写，网络层的代码。于是对于工程师来说详细了解下ISO15765还是很有必要的。

2：服务器客户端通讯方式

概念2：client/service(客户端与服务器通信模型的概念)。ISO11898中定义地通讯方式是平等（peer）方式。没有客户端和服务器的概念。

而诊断中，有一个概念就是请求（request id）和应答（respond id），设置诊断工程都会设置两个参数。概念上与客户端+服务器的概念是一致的。

3：通讯中的各种服务（service）

所有的网络层服务都具有相同的通用结构。为了定义这种服务，需要定义三种类型的服务原语：

3.1. 请求服务（Request）：

用于向网络层传递控制报文信息及要发送的数据，应用于更高层或应用层。即应用层需要调用此服务像传输层提供报文控制信息（比如数据长度这个就属于控制信息有了这个信息，传输层才知道该如何分片，如何将数据分为几片）。

3.2. 指示服务（Indication）：

用于向更高层或应用层传递状态信息及接收到的数据，应用于网络层。indication实际存在在传输层。向上传递状态信息，如传递流控制帧接收到的状态信息，和数据

具体说来，Indication前端应该执行的是底层传入数据的处理函数，即读取PDU信息，这一帧具体是SF、FC、CF还是FF。若满足条件，继续向上，即应用层传递。是不是可以理解为

有如下情况。传输层，接收到数据链路层传上来的三个连续帧，数据全部接收。然后再将数据整合好传递到应用层。

如果第一帧数据后，中间插入一个流控制帧，告诉我们先等待。那我们先等待，直到数据被全部接收

3.3 确认服务（Confirm）：

被网络层使用，用于向更高层或应用层传递状态信息。传输层向应用层传递信息。

具体说来，Confirm和Indication很像的是都是从网络层向应用层传递信息，有何区别呢？

在代码的处理中，Confirm的前端应向底层外发Tx数据或超时处理函数，反馈的信息不需要包含数据。而Indication传递的信息则分为两种，一种包含真实数据，另一种不包含。也就是说confirm是内部使用，indication1是外部使用。

举一个不太恰当的例子。你们公司在做一个很大的项目。需要一些人专门负责协调事务。confirm相当于内部的产品经理。负责协调领导和具体项目组之间的联系。

而indication就相当于对外的项目经理。主要负责协调客户与内部之间的协调和联系。

对于功能寻址（Functional addressing），只能被单帧所支持

不管发送或接收是成功或是出错，都需要上报给应用层

4 网络层时间控制分析

网络层定时参数的作用和意义：

我们知道CAN是一种对，及时性要求很高的通讯标准。同样的对于基于can通讯标准的UDS诊断协议，也是一种对实时性有一套强制性的时间标准。

不能一帧信息发送时间过长，不能请求报文帧发送出去，间隔五六秒服务器才给回复。

4.1网络层定时参数详解

网络层定时参数定义了N_As、N_Ar、N_Bs、N_Br、N_Cs、N_Cr六个参数

N_As：发送方CAN帧发送时间：从数据链路层，开始调用L_Data.confirm（就是网络层开始请求数据链路层数据开始计时），到L_Data_confirm(数据链路层确认帧发送完成)；ISO5765-2中规定，最大时间为1000ms。

N_Ar:本质上和N_As的性质是一样的，只是一个是关注发送端，一个是检查接收端。且两个时间参数的最大值=1000ms。在实际代码中可以这两个被调用的服务是一致的。只不过一个是在客户端中调用，一个是在服务器程序中进行调用。

N_Bs：发送端发送首帧后到接受到流控帧的时间。也就是L_Data_confirm，到L_Data_indication之间的时间，参数最大值=1000ms。

N_Br：接收端收到首帧后到发送流控帧的时间，也就是接受首帧后。调用L_Data_indication函数时开始计时，到L_Data_request的请求时，参数最大值=(N_Br+N_Ar)<(0.9*N_Bs)

(N_Br+N_Ar)<(0.9*N_Bs)：公式解释，直接将公式变换一下，N_Br<0.9*N_Bs-N_Ar

接收端收到首帧后到发送流控帧的时间<0.9发送端发送首帧后到接受到流控帧的时间-接受端帧的发送时间。

看图更容易理解：

 N_Cr  有两种计时方式，

1：）接收端从发送完流控制帧结束时（通过L_Data.con(FC），开始计数，到L_Data.ind(CF N_PUD)也就是到连续帧被接收端接收时。

2：）从一个连续帧被接收时，开始计时，到下一个流控制帧被接收。

 从接收端，发送流控制帧（调用L_Data.con开始算起，到收到发送端的数据（开始调用L_Data.ind）开始算起）的时间。

1:N_Cs的执行方式，也有两种，从流控帧被接收开始计时（L_Data.ind），到发送方，发送续帧请求开始(L_Data.req(CF N_PDU))。

2:从发送方发送续帧，开始确认L_Data.con(CF N_PUD)到下一帧连续帧L_Data.req(CF N_PUD)的请求时间。

注意1：发送端Sender和Receiver的理解，这是很容易误解的点。记住发送FF的实体，就是Sender，发送流控的就是Receiver。

注意2：关于Sender中的ind服务con服务计时点，与Receive中的ind服务con服务同步的问题。从理论上来说，他们之间是都没有时间误差的。这取决于帧的报文结构，大家还记得ACK位吗？

当发送端发送首诊时，检测到ACK是显性时本地的数据链路层触发con服务。同时Receive会触发ind服务，向上层的网络层提供数据。

同理Receive端发送的流控阵的con服务，也是和Sender的ind服务是同时触发的。

实际诊断过程中，诊断仪或模拟诊断上位机，和实际被诊断样件中，Sender和Receive的关系可以相互转换。

4.2 网络层定时参数解释

4.3网络层时间参数，最大值（即超时阈值）

需要说明的是N_AS或N_Ar虽然最大值默认为1000ms，但是基本实际中不会被采用，这个参数也没有啥默认价值，原因在于

N_BS最大值是1000，N_Br实际上可以理解为收到首诊，处理的过程，处理完成后，接收端将会将流控制帧发出，N_Ar也是最大值1000。即实际应用中，N_Ar肯定<900ms.

4.4：超时处理流程

4.5 对于网络层定时参数一些容易出现误解地方的详细解释

对于网络层中定时参数，定义了一个sender（发送端）和一个Receive（接收端），一定不要和client（客户端）和server（服务端）区别开来。这是两个不同的概念。

以下两个例子，就可说明

实际测试过程中，我们将上位机（或诊断仪）定义为client（客户端）。将ECU设置为server（服务器），这种设定在整个测试过程中是不会变化的。

但是，sender和Receive却不是固定的，也就是说，sender可以是客户端，也可以是服务器。同理

Receive也是如此。

比如 使用0x2E服务，由客户端（诊断仪）写入一段20个Byte的数据到ECU(服务端)，这种情况下。客户端就是sender，所有参数就要按照（N_AS,N_BS,N_CS来设定）。同理服务器端就是

Recever端，所有参数都要按照（N_Ar,N_Br，N_Cr来设定）。

如果,使用0x22 服务，读取一段内存（19个字节数据），此时客户端客户端（诊断仪）先发送一条诊断请求报文（单帧），ECU服务器发送应答（先发送首帧），然后客户端（诊断仪）发送一个流控制帧。此时客户端（诊断仪）就成为Receiver。ECU客户端就成为Sender了。

故：总结一条可以准确的定义Sender和Receiver。就是多帧的发送方，是Sender。流控帧的发送方,是Receiver。

 5：应用层定时参数

是适用于非默认会话模式的运行，

应用层定时参数的定义 说明：应用层的定时参数，是需要根据不同的会话参数区分的（如默认会话，扩展会话，编程会话等。。。）
默认会话应用层定时参数
参数定义	描述	补充说明	最小值		最大值
P2can_Client	成功发送请求消息（通过N_USData.con），到接收答复信息开始（多帧信息的N_USDataFirstFrame.ind和单帧信息N_USDataFirst）	从发送信息完成，到首帧信息收取 完成的时间。	P2can_Server_max(也就是50ms)+△P2can（△P2can分为客户端部分与服务器部分，与网关数量有关，是否需要标定） （参数值意义，暂不明确）	N/A	N/Aa
P2*can_Client	接收到否定码为0x78的否定响应码（N_USData.con） 到接收到答复信息开始（多帧信息的N_USDataFirstFrame.ind和单帧信息N_USDataFirst）	从接收78NRC到回复信息的首帧 被成功接收	P2*can_Server_max+（也就是最大允许5s的一个延时） +△P2can_rsp	N/A	N/Ab
P2can_Server	在接收到请求消息（通过N_USData.ind指示） 服务器开始答复（通过N_USData.req指示）信息的运行要求	运行要求	0	50	50ms
P2*can_Server	在传递了NRC78后（通过N_USData.con指示） 服务器开始答复信息的运行要求	运行要求	0	5000	5000ms
P2can_Client_phy	客户端成功发送，不需要应答的物理地址，请求信息（N_USData.con），到客户端能发送下一个物理地址请求信息等待的最小时间	定时器重载值	P2can_Server_max （也就是50ms）	N/A
P2can_Client_fun	客户端成功发送功能地址请求信息（通过N_USData.con指示） 到他能发送下一个功能地址请求信息的最小等待时间	定时器重载值	P2can_Server_max （也就是50ms）	N/A
1：补充说明，服务器是可以发送连续的NRC 0x78的，0x78之间的最小时间间隔为1/2P2*can_Client,最大误差为±20%的P2*can_Server（也就是5s+△P2can_rsp） 2: 客户端，发送下一个请求的最大请求时间，规范没有强制定义，但是必须满足非默认会话的S3server定时在服务器上一直运行。也就是需要一直维持在此会话模式中
						3：P2can参数，被认为是所有系统网络设计参考延时，该延时受（通过网关+总线带宽+加上安全系数） 3.1 包含网关的数量(网关数量越多，则消耗的时间则越长，网关数量越少，则消耗的时间就越短) 3.2 CAN帧的发送时间（波特率）波特率越大 3.3 CAN总线的使用情况 3.4 CAN设备驱动使用方法，（轮询方式们还是中断方式），及网络层的处理时间			△P2can又分为两部分： 1)一个是客户机发送请求到服务器的时间 2)二是服务器发送应答至客户机的时间

下图展示了△P2can的组成成分

6会话层定时参数的定义

6.1当诊断会话处于非默认会话模式时，即需要按照下表