关于Autosar中DCM（14229UDS）模块的理解

黄南山 2017-11-15

展开全文

本篇文章主要介绍基于ISO14229的DCM模块的理解。

阅读本篇文章希望达到的目的是：

UDS是干什么的，

ISO14229是如何定义规则的，

希望接下来的阅读让你不虚此行。

1. UDS是干什么的？

UDS全称是Unified Diagnostic Services，即统一诊断服务。其最重要的作用就是用来诊断汽车的故障的，当然不仅仅是这个用处，它还可以用来进行汽车的下线检测，比如一般车辆会把VIN码写入汽车中的各个零部件中（ECU），比如可以矫正角度，比如可以记录一些和产线相关的信息等等。

那么UDS是如何去诊断故障的呢？这里包含两种方式，一种为在线诊断（OBD），一种为离线诊断，前者一般用于传统燃油车中与排放相关的诊断，后者主要是非排放相关的。因为我主要做新能源汽车这一块，因此对非排放相关的诊断理解更多一点，（关于OBD 可参考ISO15031）。

那么非排放相关的故障是如何诊断的呢？首先汽车中的每个ECU都按照规则存储故障信息，例如BMS发生了欠压故障，那么这个时候BMS就记录发生故障时刻的DTC（故障码），以及在故障发生时刻便于查找故障的快照信息或冻结帧信息（例如这个时刻BMS的电压、电流等等信息），这些信息是便于查找故障的信息。

为了便于理解，有必要解释一下几个名词：

DTC：诊断故障代码，其意思就是通过一个代码代表一个故障；

快照/冻结帧：指发生故障时刻的一些便于排查故障的信息；

扩展信息：这个是指除快照之外，与故障相关的一些信息，例如故障的发生次数、老化次数等等。

以上讲了ECU是如何记录故障信息的，下一步讲我们如何去诊断我们的汽车发生了什么故障，我们接着以BMS发生了欠压故障导致车辆无法行驶为例，那么故障车一般会被拖到4s店进行维修，4s店为快速定位车发生了什么故障，这个时候他们会使用诊断仪，一键广播查找车上所有零部件上发生的故障信息，这样可以很快知道是BMS发生了故障，并且发生的故障是欠压故障，那么欠压故障是因为什么导致的呢，这个时候就要分析快照数据了，根据快照数据，快速的找到可能是因为电池包本身的电压过低导致。以上就讲完了UDS在车上是如何使用的，也就是UDS是干什么的问题。

读完这一段，你会想，UDS确实有点用处，因为你要想，车上的零部件都是成百上千的，要快速精确定位故障不是一件容易的事情，我希望你有兴趣继续读下去，下面我们就要讲讲UDS能有这种神奇功能，他是如何去规定的。

2.ISO14229是如何定义规则的？

要快速定位车上的故障，那么就要求车上所有的ECU都遵守相同的规范，同时全世界又有各种各样的主机厂，假设每个厂商都自己去定义规范，可想而知，到最后几千万上亿的车到最后可能需要各种各样的4s店。因此ISO就出台定义了一整套UDS相关的规范，这样大家都遵守一定的规范办事，也就便于后面的维护管理了（以上闲扯几句，可跳过）。

首先，我们大致推断一下ISO想干一件什么事，也就是这个规范它应对的需求是什么。

从1中提到的UDS要干的什么事，我们大致了解，这套规则需要所有的汽车厂商遵守一套协议，同时能满足所有厂商下线检测以及诊断的功能。

首先我们讲讲一般汽车厂商下线检测需要检测些什么东西，首先主机厂肯定需要的一个信息就是为生产的每一辆车分配一个标识码(VIN码，有兴趣的可百度一下)，这个VIN码可以唯一标识这辆车，下线检测的时候，就可以通过UDS写入到汽车的ECU中，所以这就会用到要写入信息的功能，但是，既然是唯一的，因此不能随便写入啊，所以就要分配权限，只能通过安全认证的人才能写入。写入之后，当然就要读出来，要不怎么知道车里面的VIN码呢。以上就引出了UDS的三个功能，读数据、写数据、以及权限检查。

当然，下线检测当然不仅仅是这些功能，例如需要调整电机的零位角度或者ECU自检等，这个时候就需要UDS支持复杂的功能，UDS管这种支持复杂功能的服务叫做例程，你可以把例程理解为一段比较复杂的逻辑程序。

有时候，我们需要去控制电路上的引脚，来调试或者检测制定的功能，例如实现一个点灯的操作，这个时候，UDS就提出了IO控制。

假如，我们想要复位一些车上的ECU，我们当然不希望还要通过拧钥匙这种操作来完成，因此UDS中提供了各种各样的复位操作；

假如，我们发生车上的某个ECU中的程序有个BUG导致车坏了，要升级怎么办，我们当然不希望拆掉一个ECU换一个，那么UDS就支持烧写程序的操作；

那么，还有一个需求就是，假如车上某个部件坏了，那么会有故障信息存储下来，这个时候为了排查故障，我们需要快速找到坏的部件，然后为了快速定位故障，我们需要知道故障发生时刻的车的状态，等车修好了，我们不需要这个存储的故障信息了，我们一般需要删掉这个故障信息，以腾出空间为后面发生的故障存储。也就是我们需要读取故障信息，以及清除故障信息的操作。

以上讲的是常用的UDS的一些操作，当然不仅仅是这些，比如烧录的时候，为了降低总线线路传输数据的负载率，一般需要控制车上各个ECU收发信息的开关，同时刚烧录的时候，一般不能开启故障存储，因为这个时候地址里面的数据不是真实发生的故障。因为UDS一般都是涉及嵌入式的软件，为了更自由的读写数据，还可以通过读写地址，当然也支持读取多个数据（规定上限4095个），因为UDS采用的是一问一答的形式，假如我们要动态实时的知道某个值怎么办，这个时候UDS当然支持周期读取数据的操作等等类似的内容。

希望你能耐心读取一下以上的需求，因为对理解14229肯定有点帮助的。

从上面对于应用场景的大致需求，我们下面一一对号入座来谈谈14229是如何定义规则。

10服务：

首先需要隆重介绍的一个服务是10服务，这个服务用来做什么？打个比方来说，假如有三个池塘，A池塘用来放草鱼和鲶鱼，B池塘用来放观赏性的锦鲤，C池塘用来放小型鲨鱼。那么我们10服务中的每个状态对应一个池塘，而每个池塘里的鱼就是14229里面对应的所有服务（所谓服务就是一套数据定义规则），里面A池塘对应10服务的默认状态，里面的草鱼和鲶鱼，对应在这种默认会话状态下支持的服务，同样B池塘对应10服务的编程模式，里面的各种锦鲤对应在编程模式下支持的各种服务。C池塘对应扩展模式，小型鲨鱼对应在该模式下支持的服务。是不是还是有点不理解，我再来简单说一下，也就是说10服务用来切换三种或更多模式，默认模式用来支持默认状态下支持的各个服务，编程模式用来支持与编程相关的服务，扩展模式一般用来在非默认模式下支持的一些服务。

为什么要这么做？其实就是为了管理各个服务，让各个服务在一个池子里面，只有进入这个池子，你才有权限去访问各个服务。

数据应答规则举例大致说明一下：

请求:CANID 02 10 03 （02对应数据长度，10表示10服务，03表示10服务的子服务，该请求的目的就是切换到扩展模式，其他模式切换类似）

答复：CANID 06 50 03 xx xx xx xx （06对应数据长度，50表示10服务（+0x40），03表示10服务的子服务，该答复的目的就是切换到扩展模式，其他模式切换类似）

有兴趣的朋友可以深入研究一下。

11服务：

对应的就是复位服务，其中包括了子服务硬件复位 01 子服务KeyOfOn复位02 子服务软件服务03；

其中三种子服务都是通过操作软件来进行对应的复位操作。

数据应答规则

请求：CANID 02 11 01

答复：CANID 02 52 01

14服务：

对应的就是清除故障服务

他可清除一个故障信息，也可以清除一组故障信息。

应答规则后面不讲了，有兴趣的朋友可支持参考14229协议。

19服务：

这个服务主要用来，查询故障信息，这个服务非常复杂，需要费很大的力气才能讲清楚，下面我仅仅对常用的几种子服务进行介绍，其实所有定义的服务，无非就是为了快速查找到需要的故障信息。

01子服务：通过状态掩码的形式去，查找该状态掩码匹配的故障个数，其实意思就是查找故障个数，这里稍微解释一下状态掩码，在UDS规定里面，每个故障都对应8个状态，每个状态对应一个bit，比如状态0对应bit0，表示当前发生的故障，状态3对应bit3，表示已经确认的故障等等，那么状态掩码的意思就是用一个8bit的数去按位与，如果与的结果与的结果非0表示匹配到了，然后故障数就++。

02子服务：通过状态掩码的形式去，查找匹配的故障，以及故障的状态。

04子服务：请求指定故障码（DTC）的快照信息，意思就是说为了找到故障的原因，查找故障发生时刻的一些数据，来分析故障原因。

06子服务：请求指定故障码（DTC）的扩展信息，就是想了解一些该故障的一些其他信息，比如发生的次数、自恢复的次数等，具体数据可自定义。

0A子服务：通过该服务科获取所有支持的故障码和故障状态信息，注意是所有的故障及故障码。

这个服务大致简单的讲到这里吧，其实这个服务里面有N多内容，需要细细挖掘掌握。

22服务：

通过数据标识符的形式读取数据，例如我想读电机控制器里面的电机转速的信息，我就定义电机转速这个变量标识符为0x2000，（这是因为总线上基本不搞变量啊），所以我去请求电机转速时，我只需读该标识符的数据即可。

2E服务：

与22服务对应，表示通过数据标识符写入数据，一般来说，一个标识符可支持读，写操作是根据需求可选的。

23/3D服务：

23是通过地址读数据

3D是通过地址写入数据，一般用的较少。