UDS协议在电动两轮车的应用

一、背景

在以往的电动车型上应用层通信协议基本都是采用了私有协议，由于是自定义的，故而会存在诸如规范性、灵活性不高等问题，比如跟配件厂商进行通信时需要双方约定好协议格式等。为了解决这些问题，我们在今年预研的新车型项目中尝试引入了汽车行业标准的统一诊断服务协议UDS（Unified Diagnostic Services）。

新车型主要有三大核心部件，如整车控制器VCU（Vehicle Control Unit）、电机控制器MC（Motor Control）、电池管理系统BMS（Battery Management System）。三者之间底层通信沿用旧车型上采用的标准控制器局域网总线CAN（Controller Area Network）协议，如下图1所示。下面介绍下什么是UDS协议以及根据此协议编写的软件SDK，供VCU、MC、BMS使用，避免重复造轮子。

图1 三大件底层通信框架

二、UDS协议介绍

2.1 简介

UDS统一诊断服务协议（Unified Diagnostic Services）是一套针对于整车诊断的协议，标准是ISO-14229，不同于OBD（On-Board Diagnostics）只是针对排放类的ECU（Electronic Control Unit）的协议，其可以向整车内所有ECU发送请求数据进行诊断，比如自动变速箱有没有问题、防抱死系统有没有问题等。

UDS提供的是一个诊断服务的基本框架，使用者如主机厂和零部件供应商可以根据实际情况选择实现其中的一部分或是自定义出一些私有化的诊断服务，灵活性很高。从软件层面上来讲，UDS遵循ISO七层模型，属于是应用层的协议，网络层以下支持多种标准协议，如CAN协议、IP协议、LIN总线协议等，其框架模型如下图 2 所示。

图2 UDS协议框架

2.2 应用层服务说明

应用层服务通常被称为诊断服务。应用层服务用于基于客户端 - 服务器的系统，以执行诸如测试、检查、监控或诊断车载车辆服务器等功能。通常被称为外部测试设备的客户端使用应用层服务来请求在一个或多个服务器中执行诊断功能。 

服务器通常是 ECU 的一部分，它使用应用层服务将请求的诊断服务提供的响应数据发送回客户端。 客户端通常是板外测试器，但在某些系统中也可以是板上测试器。 应用层服务的使用与作为板外或板上测试器的客户端无关。

通过上面 2.1 小节的介绍，可以知道 UDS 只是一套协议规范，网络层以下可以支持多种不同类型的协议，那么它是怎么做到的呢？方法就是UDS定义了一种通用的服务格式，属于描述性语言，所有应用层服务都采用了这种格式，具体如下图 3 所示。

图3 服务格式

其中 type 类型共有六种，分别是请求Request、指示Indication、应答Response、确认Confirm、请求确认Req_confirm、应答确认Res_confirm。每种服务原语类型格式都遵循上述服务格式，所带参数基本雷同，如Request请求实际格式所带参数如下图4所示。  

图4 请求服务原语格式

其中参数A_Mtype代表是诊断类型还是远程诊断类型；A_SA代表源地址，记录发起请求的一方地址信息；A_TA代表目的地址，表明接收者是谁；A_TA_type代表地址类型是物理功能还是通用功能；A_AE代表扩展地址，可选；A_Length代表请求数据的长度；A_Data代表的是具体的请求数据内容。  

那实际中UDS提供了什么样的诊断协议框架呢？从软件层面上来说，UDS提供了6大类共26类服务协议框架，基本包含了众多车辆厂商需要使用的功能，分别是诊断和通信管理功能单元、数据传输功能单元、存储数据传输功能单元、控制功能单元、常规功能单元、上传下载功能单元。26类服务中每种具体的服务功能如下图5所示。

图5 26类具体服务名

有了上述所介绍的服务以及服务格式之后，具像化到软件程序代码层面上来实现时是

怎么样的呢？也就是上述介绍的服务格式里的A_Data内容格式是怎么样的呢？拿请求Request类来说（其它服务原语相似），UDS提供了四种原型语句，如下：

1、SID（内容仅有SID，即服务ID，也就是上面26类具体服务的ID，如ECUReset

是0x11）

2、SID+SF（SF代表子函数，即每一类服务里面再细分的功能定义）

3、SID+DID（DID代表Data Identifer，即身份标识，每个DID定义既可以使用UDS提供的固定代表值，如0xF18A代表系统供应商名称，也可以由各类车辆厂商自定义）

4、SID+SF+DID

客户端或者服务器收到请求语句后UDS也提供了两种对应的响应语句格式，如下：

1、积极响应：请求语句其余内容不变，只有SID变成了SID加上64后的值

2、否定响应：固定格式为0x7F+SID+NRC（NRC代表否定代码，UDS定义了通用的否定代码供使用者使用）

UDS的请求语句内容A_Data组装填充好后变成了A_PDU（A代表应用层的缩写、PDU是Payload Data Unit），之后由实际的网络层采用的通信协议进行数据再次组装后进行传输，完成通信的功能，其通信模型按照七层ISO模型来说如下图6所示。

图6 UDS 通信模型

2.3 特点归纳

1、协议标准化，众多车辆厂商共同遵循，无缝接入。 2、协议灵活性高，可扩展性强，UDS除了定义好基本包含常用功能的协议框架外，还预留了许多字段可供厂商自定义。 3、协议兼容性好，UDS定义了一套通用应用服务格式，网络层下可以支持多种标准通信协议作为实际数据传输载体。  

那UDS请求数据到达网络层之后又是怎么再次组装数据的呢？怎么提供数据的单帧、多帧的格式定义呢？这就是接下来要介绍的新项目中采用的标准CAN协议。

三、CAN协议介绍 

CAN协议是控制器局域网总线的简称，是一种用于实时应用的串行通讯协议总线，它可以使用双绞线来传输信号，是世界上应用最广泛的现场总线之一，常应用于汽车电子各部件间通信、工业领域等。

其标准主要有CAN2.0A和CAN2.0B两部分，A标准主要描述标准帧格式，B主要描述扩展帧格式。实际物理层中采用两根线（CAN_H，CAN_L）之间的差分信号进行传输数据，抗干扰能力强，容错能力也强，速率可达1Mbps（通信距离小于40M）。其物理层定义和两种协议帧格式如下图7和图8所示：

图7 CAN协议物理层定义

图8 CAN协议两种帧格式定义

上述物理信号中逻辑 0 代表显性信号，优先级最高，1 代表隐性信号，优先级最低。数据帧中格式一般由 7 个段组成，分别是帧起始、仲裁段、控制段、数据段、CRC段、ACK段、帧结束。单帧最多能传输8个字节数据。

CAN协议标准较多，其中新项目中采用的是ISO-15765，文档定义了数据传输（单帧和多帧）的标准，所有数据域（即上图8里的Data段）格式命名为N_PDU（N代表网络层缩写，PDU同A_PDU），有三部分组成，第一部分是N_AI（地址信息，类型包括目的地址、源地址等，大部分是目的地址，例如宝马车系统上就是目的地址），N_PCI（协议控制信息，一般集中在前三个字节里，此部分就是定义了数据是单帧还是多帧），N_Data（数据域，使用者自己定义的），如下图9所示：

图9 N_PDU格式

帧类型说明如下：

单帧：当N_PCItype = 0时，表示此帧为单帧SF，SF_DL为此次单包传输的数据量，最大6字节。

首帧：当N_PCItype = 1时，表示此帧为多帧数据中的首帧FF，FF_DL为此次多帧传输的数据量，FF_DL的最大值为4095。

连续帧：当N_PCItype = 2时，表示此帧为多帧数据中的连续帧CF，也叫序列帧，SN为序列帧的计数，用于数据的有序传输，第一次发送SN的值为1（即多帧的第二帧起始值就是固定的0x21），当SN的值溢出时，SN从0开始计数。

流控帧：当N_PCItype = 3时，表示此帧为流控帧FC，FS为数据流传输的状态信息，BS为接收方发送流控帧的间隔（以CF帧为单位），ST为发送方间隔发送序列帧的时间间隔。具体值代表如下图10所示：

图10 流控帧参数定义

其中单帧数据发送很简单，每帧发即可，多帧数据发送流程如下图11所示：

图11 多帧数据发送流程

简单来说，多帧发送数据流程就是：

1、发送方先发送首帧(FF)，告诉对方我要发送FF_DL长度的数据及N-2字节的数据
    2、接收方收到首帧后，发送流控帧（FC），告诉发送方流控的状态（FS）以及接收数据的能力（ST）和下一次发送流控帧的间隔（BS）
    3、发送方接收到流控帧后，就按照ST的时间间隔发送按SN计数的序列帧（CF），每帧序列帧有N-1 字节的数据
    4、发送方发送BS数量的序列帧（CF）后，等待流控帧，如果BS等于零，则此步骤省略
    5、发送方如果最后发送的序列帧数量小于BS，则不用等待流控帧，传输结束

通过上述二、三章节从应用层到网络层即自上而下的介绍完所用的UDS服务协议框架后，接下来介绍下基于此服务协议框架实现的具体软件SDK（Software Development Kit，即软件开发工具包）功能。

四、UDS SDK介绍

4.1 SDK简介

UDS SDK设计的目的除了是引入汽车行业标准UDS服务协议以外，还为了避免重复造轮子，减少开发人力，提高效率。因为目前新项目中的三大件VCU、MC、BMS都采用了UDS协议，那么就都可以通过此SDK接入，完成UDS协议的使用，理论上新项目中其余采用底层CAN通信的配件都可以采用此SDK完成UDS协议的通信交互。

本SDK在实现之前参考学习了一些通用的规范，如变量、函数和文件命名采用Linux小写风格还是大驼峰等风格，因为UDS协议里定义的一些变量名和服务名都是大驼峰，所以本SDK为了一致，在实现上也统一采用了大驼峰风格；从软件分层方面来说，主要考虑易用、易理解、高内聚低耦合以及为了能迁移不同平台等原则，采用了嵌入式系统里常用的三层结构，自上而下分别是应用层、网络层、硬件移植层，层级结构如下图12所示。

图12 UDS SDK软件框架

应用层：

1、此层主要映射实现的就是上述第二章节介绍的UDS协议里的所有服务功能

2、负责对网络层第一次解析后透传过来的UDS数据进行再次解析

3、数据解析后负责调用对应的UDS服务、完成具体应用功能

4、按照规范实现对外的API（Application Programming Interface）供SDK使用者使用，完成SDK的运转

网络层：

1、此层映射的就是上述第三章节介绍的CAN协议，主要实现协议的单帧、多帧数据的相关处理

2、负责对硬件底层收到的数据按照ISO-15765-2协议标准进行解析以及对应用层传递过来的UDS数据协议进行组装处理并传递到硬件底层进行数据传输

3、负责底层数据解析后按照ISO-15765-2协议进行数据往上层应用层通知及回复发送者等交互逻辑

4、数据异常处理，包括超时、协议格式错误、数据长度错误等

硬件层：

1、此层主要是为了实现SDK的平台兼容性，可以迁移不同平台环境而约定好的一些功能接口

2、需要各SDK使用者针对使用的平台环境如单片机MCU（Microcontroller Unit）类型进行移植实现

3、主要有CAN的初始化、反初始化、发送数据、接收数据、1ms频率的定时计数、操作系统平台统一接口CMSIS（Cortex Microcontroller Software Interface Standard）的实现，主要有任务创建、互斥锁等

本SDK为了使用者使用简单，见名知义，在软件代码层面上提供了使用详细说明文档、参考例子、代码目录结构以及文件夹命名采用通俗易懂、高内聚低耦合的原则，整体分为五个文件夹、一份说明文档、一个配置文件，具体如下图13所示。

图13 SDK代码目录结构说明

所以SDK的使用上也比较简单，使用者先配置自身的使用环境，之后再移植实现硬件层SDK要求的对应功能，最后就是重写实现具体使用的UDS服务功能即可。

SDK的主要特点：

1、支持标准UDS协议解析（ISO-14229）

2、支持单帧及多帧数据协议（ISO15765-2）

3、支持队列循环处理及数据异常处理

4、支持CAN标准帧协议

5、支持裸机和RTOS环境

6、支持迁移不同嵌入式平台，只需移植对应的硬件层功能

2.SDK落地

目前SDK已落地在预研的新项目中、VCU、MC、BMS三大核心部件都在使用。SDK的版本也在随着协议的增加而迭代，目前已迭代到V3.0版本。

五、结语

本文主要是介绍了新车型项目中首次引入的汽车行业标准中的UDS服务协议，从UDS的协议框架中自上而下的从应用层到网络层支持的协议之一CAN协议整体介绍了何为UDS协议以及在实际中的使用。相信随着此次新项目的首次尝试，未来我们两轮车自研能力会越来越强，标准会越来越趋于国标，引领行业。

审核编辑：汤梓红