我要投搞

标签云

收藏小站

爱尚经典语录、名言、句子、散文、日志、唯美图片

当前位置:博发彩票 > 多总线 >

关于基于XCP协议支持多总线的ECU标定系统的实现

归档日期:04-26       文本归类:多总线      文章编辑:爱尚语录

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

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

  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总线 XCP协议驱动程序的实现

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

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

  从节点设备启动并完成初始化后,会立刻检测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数据包,其第二字节包含具体的错误码。

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

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

  XCP报文分为3部分,分别是报文头(XCP Header)、报文尾(XCP Tail)和中间的XCP数据包(XCP Packet)。其中XCP数据包由协议层定义,报文头和报文尾由传输层定义,从而实现同一协议层数据包可通过不同物理总线 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相等。

  当物理层传输介质为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总线]。本文设计的FlexRay数据帧采用最为简洁的形式,仅包含一个XCP报文。

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

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

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

本文链接:http://dixiebandcamp.net/duozongxian/9.html

上一篇:没有了

下一篇:基于树莓派的多串口多总线服务器设计