0 引言

汽车技术的飞速发展使得汽车电子控制单元（Electronic Control Unit，ECU）中包含的控制参数大量增加，标定工作复杂度越来越高。在ECU开发过程中，控制参数的标定工作直接影响整车性能的优劣。面对日趋多样的ECU和通信总线类型，开发一种支持多总线的、通用灵活的标定系统，具有非常高的实用价值^[1]。目前，CAN总线作为一种可靠的汽车总线已经广泛应用于高档汽车，因而多数标定系统都是基于CCP（CAN Calibration Protocol）协议开发的，具有一定的通用性^[2]。但随着更为先进的FlexRay通信总线迅速发展，开发出一种既支持当下主流的CAN总线，又兼容代表汽车总线趋势的FlexRay总线的标定系统，无疑具有很高的技术应用价值。

本文基于XCP协议设计了一套ECU标定系统，充分利用了XCP协议物理传输层与协议层相互独立的特性，基于同一协议层分别实现了对CAN总线和FlexRay总线的支持，大大提高了标定系统的总线兼容性与可扩展性。

1 标定系统总体方案设计

XCP协议由自动化及测量系统标准协会（Association for Standardization of Automation and Measuring system，ASAM）提出，是对原有CCP2.1协议的继承和升级，力求使用最小的系统和硬件资源开销实现高效通信^[3]。该协议分别定义了协议层、传输层和接口层，其最突出的特点就是协议层独立于传输层。对于不同类型的通信总线，只需要将XCP报文（XCP Message）的报文头和报文尾填上对应信息，而中间部分的XCP数据包（XCP Packet）由协议层定义，完全不受影响。因此XCP标定协议能够极好地适应总线多样化对标定系统通用性提出的要求。目前，ASAM已经在标准中定义的传输层包括：XCP-on-CAN、XCP-on-Ethernet（TCP/IP、UDP/IP）、XCP-on-SXI（SPI、SCI）、XCP-on-USB和XCP-on-FlexRay^[3]。根据后续的实际需求，也考虑进一步定义XCP-on-LIN、XCP-on-K-Line和XCP-on-MOST。

图1是标定系统总体架构设计方案。整个标定系统框架遵循ASAM-MCD标准（原ASAP标准）搭建，包括运行于PC端的上位机标定软件、负责上位机和下位机之间通信的通信控制单元和下位机ECU。ECU端采用Freescale公司的MC9S12XF512芯片。上位机集成了方便用户进行测量和标定的图形界面以及XCP命令解析模块，用户请求经由上位机XCP协议模块打包，通过通信控制单元发送至下位机ECU通信接口，再由集成在ECU中的XCP驱动模块解析后调用对应命令处理模块进行操作，将处理结果打包并通过通信控制单元发送回上位机。根据通信介质的不同，需要对XCP协议帧的帧头和帧尾进行对应的信息填充。本文设计的标定系统同时支持当下主流的CAN通信总线和代表未来汽车总线发展趋势的FlexRay总线。

2 XCP协议驱动程序的实现

XCP协议以主从方式工作，并使用命令传输对象（Command Transfer Object，CTO）和数据传输对象（Data Transfer Object，DTO）两种数据包来区分主从节点间的通信，如图2所示。

XCP协议规定了3种通信模式，分别是标准通信模式(Standard Mode)、块传输通信模式(Block Transfer Mode)和交错传输通信模式(Interleaved Mode)。本文设计的标定系统适用于CAN总线和FlexRay总线，采用标准通信模式，即在主机主动发起会话建立连接之后，对于主机发送的每一条命令，从机都必须进行响应处理，如出错则返回错误报告信息。在没有接收到从机对上一条命令的应答之前，主机不会发送新的命令^[4]。

2.1 下位机端XCP协议驱动程序的实现

XCP协议作为对CCP协议的升级，其所具有的一个重要新功能是对冷启动测量的支持，即所谓的RESUME模式^[3]。集成了XCP协议驱动的下位机启动后其状态机模型如图3所示。

从节点设备启动并完成初始化后，会立刻检测ECU的非易失存储介质中是否有已配置好的DAQ list供RESUME模式使用，如果有，则进入RESUME模式，按配置列表周期性向上位机发送数据；如果没有相关配置文件，则进入DICONNECTED模式。在RESUME模式和DISCONNECTED模式下，从设备只响应来自主机的CON-NECT命令(XCP-ON-CAN条件下还可响应GET_SLAVE_ID命令)。下位机端XCP驱动的工作流程如图4所示。

按照主从通信模式，从机端使用中断方式对主机的命令进行响应。从机启动后会首先完成系统的初始化工作，包括对从机硬件资源的初始化、配置系统默认参数以及XCP模块的初始化，并且将标定数据从ROM或Flash镜像到RAM，为标定工作做好准备。在解析到来自主机的CTO消息中包含CONNECT命令后，从机响应主机建立连接，该设备进入在线状态，进而处理来自主机的一系列命令，并根据命令码（CMD code）调用对应的模块进行响应，完成对应操作后将数据封装成DTO数据包发送给主机。如处理出错，则返回对应的ERR数据包，其第二字节包含具体的错误码。

2.2 上位机端XCP协议驱动程序的实现

上位机采用图形化编程语言LabVIEW开发。XCP协议共规定了18条必选命令和38条可选命令^[5]。结合标定系统的功能需求和开发语言特点，实现思路是将18条必选命令和部分可选命令分别定义为独立的子vi，然后根据实际功能需求对其进行顺序调用。实现的部分命令子vi如图5所示。

结合标定软件的功能需求和XCP协议规定的CMD列表，上位机端的XCP协议实现框架如图6所示。

本文设计的标定系统软件包含部分尚未实现的可选命令。当用户操作需要用到该命令时，下位机会统一返回ERR_CMD_UNKNOWN错误代码。

3 XCP协议传输层设计

作为对CCP协议的升级，XCP协议最突出的特点是协议层独立于具体的物理传输层，从而增加了协议对总线适用的灵活性，减少了开发移植的重复工作。XCP协议规定的XCP报文(XCP Message，也称XCP Frame)结构如图7所示。

XCP报文分为3部分，分别是报文头(XCP Header)、报文尾(XCP Tail)和中间的XCP数据包(XCP Packet)。其中XCP数据包由协议层定义，报文头和报文尾由传输层定义，从而实现同一协议层数据包可通过不同物理总线进行传输。

3.1 XCP-on-CAN传输层设计

当物理层传输介质为CAN总线时，报文头为空，报文尾由开发者根据实际需求选则有或者无，且XCP数据包中不包含时间标识段(TIMESTAMP)。其原理是：CAN2.1协议规定CAN报文数据帧的数据域长度DLC最多为8 B^[6]。如果设置CAN报文中的数据长度DLC始终等于XCP数据包长度LEN，则报文尾为空，此时XCP数据包就是XCP报文；如果设定DLC长度始终为MAX_DLC=8，则当XCP数据包长度小于8 B时，需要通过添加XCP报文尾的方式补足8 B（填充内容任意）。本文设计的XCP-on-CAN报文采用第一种方式，即令DLC始终与LEN相等。

3.2 XCP-on-FlexRay传输层设计

当物理层传输介质为FlexRay总线时，必包含报文头，而报文尾则根据所在报文实际情况，可能为空，也可能为1 B的填充域(填充内容任意)。其原理是：报文头包含4个部分，分别为XCP节点地址(NAX)、计数(CTR)、填充字节(FILL)和XCP报文数(LEN)。除首字节NAX外，其余部分均为可选项。FlexRay作为新一代高速总线，每一帧的理论有效数据长度能达到254 B，实际应用过程中有效数据长度取决于具体的FlexRay控制器参数，其中恩智浦MFR4310控制器已经可以实现0～254 B数据域长度配置^[7]。为了增加总线吞吐量，当FlexRay数据帧中含有多个连续的XCP报文时，需要给每一个报文顺序计数CTR以保证数据的有序性，同时还要给出所包含的XCP报文个数LEN，而FILL域用于实现Byte或Word对齐，提高FlexRay总线传输效率^[8]。本文设计的FlexRay数据帧采用最为简洁的形式，仅包含一个XCP报文。

本文设计的XCP-on-CAN和XCP-on-FlexRay报文结构如图8所示。

4 标定系统验证

对系统进行验证的首要目标是保证系统的各项基本功能均能够准确、可靠地实现。验证的基本思路是：第一阶段，连接标定系统上位机、下位机，并运行上位机标定软件，将下位机ECU上电，通过简单的配置后可以实现上、下位机的成功连接。而后建立监测窗口，选取若干参数进行数据显示，观察是否能正常运行；再建立标定窗口，对上述某一参数数值进行修改，从而验证标定系统的基本功能。第二阶段，连接本文开发的标定系统和实验室一直使用的电池包管理ECU，重复上述验证程序，验证标定系统的适用性。实验结果表明该系统使用简单灵活，能够满足实验室标定工作的基本需求。标定系统工作时的连接参数配置界面、监测窗口和标定窗口如图9所示。

5 结论

本文基于XCP协议完成了ECU标定系统的开发，按照ASAM-MCD标准设计系统整体架构并予以实现，保证了系统的通用性。利用其协议层独立于传输层的特性，在同一协议层的基础上设计了CAN总线和FlexRay总线对应的两种传输层结构，克服了基于CCP协议的标定系统仅支持CAN总线的局限性。最后应用标定系统进行标定试验，验证其监测、标定等基本功能。本文设计的标定系统具有良好的总线适用性和可扩展性，不仅满足当下主流CAN总线的标定需求，而且支持新一代FlexRay总线。与此同时，XCP协议多总线支持的特性也为今后进一步扩展XCP-on-Ethernet、XCP-on-SXI和XCP-on-MOST提供了保证。

参考文献

[1] 张俊峰，肖兵，童天涯.面向异构网络的整车控制器标定系统的实现[J].电子技术应用，2015，41(12)：133-136.

[2] 刘运潇.基于CCP的通用型ECU标定系统研究和设计[D].上海：上海交通大学，2013.

[3] SCHUERMANS R，ZAISER R，HEPPERLE F，et al.XCP_Part1-Overview_V1-1-0[Z].2008.

[4] 苏瑜，周文华，竺春狄.一种适用不同通信方式基于XCP协议的ECU标定工具的开发[J].汽车工程，2010，32(1)：81-85.

[5] SCHUERMANS R，ZAISER R，HEPPERLE F，et al.XCP_Part2-Protocol layer specification_V1-1-0[Z].2008.

[6] SCHUERMANS R，ZAISER R，HEPPERLE F，et al. XCP_Part3-Transport layer specification_XCPonCAN_V1-1-0[Z].2008.

[7] 王晓阳.基于FlexRay轮毂电机汽车XCP标定系统研究[D].北京：北京交通大学，2014.

[8] CUMMINGS R.Easing the transition of system designs from CAN to FlexRay[C].SAE World Congress & Exhibition，2008.

作者信息:

任银行，张建龙，殷承良

（上海交通大学 机械与动力工程学院，上海200240）