ISO14229系列，涵盖了UDS的服务定义以及在各车载总线上的一些特殊应用指导，以及各总线类型所对应的下层协议要求，下面就是该系列中各协议所对应的内容清单。
| 协议编号 | 协议名称 | 协议内容 |
|---|---|---|
| 14229-1 | Application layer | UDS的使用规则，服务，以及相关的服务原语(接口定义) |
| 14229-2 | Session layer services | 会话层的使用规则 |
| 14229-3 | UDSonCAN | 在CAN总线上应用时一些特殊服务规则和其他层遵循的协议要求 |
| 14229-4 | UDSonFR | 在Flexray总线上应用时一些特殊服务规则和其他层遵循的协议要求 |
| 14229-5 | UDSonIP | 在Ethernet上应用时一些特殊服务规则和其他层遵循的协议要求 |
| 14229-6 | UDSonK-Line | 在K线上应用时一些特殊服务规则和其他层遵循的协议要求 |
| 14229-7 | UDSonLIN | 在LIN总线上应用时一些特殊服务规则和其他层遵循的协议要求 |
| 14229-8 | UDSonCXPI | 在CXPI总线上应用时一些特殊服务规则和其他层遵循的协议要求 |
通过上表可以看出，ISO14229-1和ISO14229-2是该系列的核心基础，而其他协议则是将UDS在每种总线类型上应用所需要注意的一些特殊要求，以及其对应的其他层所使用的协议。所以学习UDS的重点，就在学习ISO14229-1和ISO14229-2上面，同时，这两个协议也是最难学的一部分。
这篇文章主要来介绍ISO14229-1里的基础部分，诊断的规则。
很多人讲这一部分，都会按ISO的思路，按照服务原语→服务规则→否定响应规则→服务定义顺序来讲，这里，我把服务原语的内容，先留作大家自己去学习进阶的内容，在讲完CAN总线的时候，作为进阶补充来写。为什么这么做？因为很多人在实际工作和使用UDS的时候呢，实际并不是太关注实际每层之间如何传递参数，传递哪些参数，所以这里先捡大家实际用得上的内容进行分享。
一、基本概念
在说服务规则之前，首先大家要知道几个概念，我先列举并解释一下这些概念。
客户端、服务端：在UDS的规则里面，有两个角色是大家一定要知道的，就是客户端(client)和服务端(server)，实际应用过程中，它们是成对出现的。这两个角色与我们通常了解的网络或软件的概念是一致的，客户端指的就是要使用服务器的一方，比如我们有微信客户端、邮箱客户端、游戏客户端等等，这些都是本地的应用，必须使用服务器的数据才能实现其功能。而服务端相当于我们平时所认识到的服务器，它用来提供服务给客户端使用，来交换数据。总结一下就是，客户端按照UDS协议的规定可以向服务器请求某些服务，来实现数据的交互。在汽车上，客户端指诊断仪或具备诊断仪功能（发送诊断请求）的设备和ECU，服务端指实际执行请求命令的ECU。
请求、响应：有了客户端和服务端，那么它们的交互是如何实现的呢？对，就是通过请求和响应来实现的，客户端可以通过请求来向服务端索要数据，也可以通过请求来向服务端发送数据，服务端收到请求后，需要按照规则来给客户端响应，来实现具体的服务功能。响应分为肯定响应和否定响应，即请求的事务被正确处理时服务端给出肯定响应，请求的事务无法处理或处理时发生错误时服务端给出否定响应。否定响应包含被否定的服务ID和否定响应码（NRC）。
地址：我们在浏览网络的时候，需要在地址栏输入网址，之后才能够访问我们所想要访问的内容，这件事情在UDS里面也是如此。每个服务端都有一组地址请求地址和响应地址，其中请求地址又分为物理寻址和功能寻址，也就是说每个服务端至少都有三个地址：功能请求地址、物理请求地址和响应地址。每个地址里面包含了目标地址和源地址，即不管是请求地址还是响应地址，地址信息里都包含了发送方和接收方的信息。有关地址格式的说明，会在ISO15765系列里详细说明，这里只要记住每个服务端都有这三个地址即可。
物理请求地址：一对一请求地址，即该地址指向的是单一服务器，可以理解为打电话，请求是由客户端发送给指定的服务端的，只有指定的服务端能对此请求进行响应，且如无特殊要求，必须响应。
功能请求地址：一对多请求地址，即该地址指向的是一组服务器，可以理解为电话会议，请求是由客户端发送给指定的多个服务端的，被请求的服务端都能够对请求进行响应，例如一般车上的功能寻址都是请求所有的控制器的。但是功能寻址所请求的内容如果不支持，是可以不响应的，具体细节在响应规则章节会说明。
响应地址：响应地址不区分物理还是功能，因为响应的发送方和接收方是唯一的，即只有一对一的场景。
服务ID：UDS是以诊断服务来划分功能的，每个服务分配一个特定的ID，占用一个字节长度，每个服务根据功能的不同会有不同的格式，但基本上有带子功能和不带子功能之分，这个在讲格式的时候会详细进行说明。
子功能：一些服务如10会话模式服务，会有不同的会话模式，19服务会包含读取故障码和快照等其他信息的功能，所以这些功能会用子功能进行区分，表示同类功能下的细分类别。子功能同样也占一个字节。
数据参数：大部分服务都需要数据参数才能确认请求的具体内容，例如22服务需要DID参数才能够确定要读取哪个数据，19服务需要指定参数才能确定读取的是哪一类或者哪个故障的数据等。
抑制肯定响应位：子功能的最高位，用来表示对该请求的响应要求，如果该位置1，则当前请求的肯定响应是不需要响应的，反之则需要响应。
否定响应码（NRC）：当服务端处理请求出现问题时，需要给出的问题原因。ISO14229-1的附录A有一张否定响应码的表格，里面有每个码所代表的含义，同时在通用响应规则和每个服务的响应规则里也会指出具体在哪些步骤进行响应。
二、响应规则
UDS中，一般由客户端发起诊断请求，服务端进行响应，每次对话都是一问一答的形式，但是有些时候，一些特定的请求是可以不用响应的，接下来按照14229-1的四张表格，分别说说这响应的具体规则。
为什么是四张表格？因为是根据物理寻址和功能寻址，带子功能和不带子功能，这两个属性排列组合，组成了四种情况。
1.物理寻址带子功能的请求
这张表格，按照抑制肯定响应位，分为上下两部分，除抑制肯定响应位之外，所列举的情况均一致，不同的地方在于如何响应。在阅读的时候，可以上下两部分同时进行对比，加深印象。
①a和f条件一致，服务和子功能都支持，所请求的参数至少有一个是支持的，这时候a需要肯定响应，而f则不需要响应，所以f是抑制肯定响应位导致的不需要响应。
②b和g条件一致，服务和子功能都支持，虽然至少有一个参数是支持的，但是看最后一列备注所指出的内容，当处理这个支持的参数出现问题的时候，回复否定响应。否定响应的内容这里给了一个XX替代，意思是根据实际情况进行响应。
③c和h条件一致，服务和子功能都支持，请求的参数都不支持，所以响应是NRC ROOR，即请求超出范围，这里的范围指的是支持的数据参数范围。
④d和i条件一致，服务不支持，这里分两种情况，一种是服务端不支持请求的服务，另一种是请求的服务在当前的会话模式不支持，因此这里NRC有两个。
⑤e和j条件一致，都是子功能不支持，同样这里也分两种情况，一种是服务端不支持请求服务的子功能，另一种是请求服务的子功能在当前的会话模式不支持，因此这里NRC有两个。
通过对比可以发现，抑制肯定响应位作用就是当响应为肯定响应时，无需进行响应，而其他情况的响应规则是相同的。
2.功能寻址带子功能的请求
这张表格，同样按照抑制肯定响应位，分为上下两部分，除抑制肯定响应位之外，所列举的情况均一致，不同的地方在于如何响应。在阅读的时候，可以上下两部分同时进行对比，加深印象。
①a和f条件一致，服务和子功能都支持，所请求的参数至少有一个是支持的，这时候a需要肯定响应，而f则不需要响应，所以f是抑制肯定响应位导致的不需要响应。
②b和g条件一致，服务和子功能都支持，虽然至少有一个参数是支持的，但是看最后一列备注所指出的内容，当处理这个支持的参数出现问题的时候，回复否定响应。否定响应的内容这里给了一个XX替代，意思是根据实际情况进行响应。
③c和h条件一致，服务和子功能都支持，请求的参数都不支持，这时候不需要进行响应。
④d和i条件一致，服务不支持，这时候不需要进行响应。
⑤e和j条件一致，都是子功能不支持，这时候不需要进行响应。
和上一节进行对比，可以看到在③、④、⑤这三种情况的时候，功能寻址的请求是不需要服务端进行响应的，这就是物理寻址请求和功能寻址请求的响应规则上的差别，这里一定要记住，这三种情况下的NRC，功能寻址不需要响应。但是，这里有一个例外，就是如果服务端首先回复了NRC78（pending），那么接下来就必须有后续的响应，直到响应了其他NRC或者给出了肯定响应。
3.物理寻址不带子功能的请求
这个表格可以看出来，没有了子功能，就没有抑制肯定响应位什么事儿了，这里情况就剩下了一半，所以要记住抑制肯定响应位的含义和使用方法。
a)请求中的服务和所有参数都支持，这时候不用想，必须是肯定响应。
b)请求中的服务和至少一个参数支持，这时候只响应支持的参数即可，也需要给出肯定响应。
c)请求中的服务和至少一个参数支持，但是处理参数的时候发生了错误，这时候就需要根据实际情况给出否定响应并给出具体的否定响应码（NRC）。
d)请求中的服务是支持的，但是参数都不支持，这时候需要给出否定响应NRC31，也就是说请求的数据超出了服务端所支持的范围。
e)请求中的服务是不支持的，需要给出否定响应，这个跟之前的情况一样，分两种情况，分别是服务不支持（NRC11）和当前会话模式不支持该服务（NRC7F）。
4.功能寻址不带子功能的请求
这个表格和上一节的表格区别在于d和e两个请求，在请求是功能寻址的时候，这两种情况是不需要给出响应的。
a)请求中的服务和所有参数都支持，这时候不用想，必须是肯定响应。
b)请求中的服务和至少一个参数支持，这时候只响应支持的参数即可，也需要给出肯定响应。
c)请求中的服务和至少一个参数支持，但是处理参数的时候发生了错误，这时候就需要根据实际情况给出否定响应并给出具体的否定响应码（NRC）。
d)请求中的服务是支持的，但是参数都不支持，这时候说明请求的数据超出了服务端所支持的范围，服务端不需要给出响应。
e)请求中的服务是不支持的，服务端不需要给出响应。
综合以上四个小结，可以得到这样一个结论，功能寻址的请求，如果请求中所包含的服务、子功能、参数是不被服务端支持的，那么服务端无需对该请求给出响应。
扫一扫
353
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
