XCP协议和A2L文件 – XCP协议解析 Part 1

发布: Edward  •  分类: Protocol  •  June 17, 2017, 9:43 p.m.  •  编辑

在接下来的两篇文章中,我们将主要通过XCPonCAN(即XCP运行在CAN传输层上)来仔细讲解XCP协议层的内容。本篇文章主要侧重于XCP协议层中的通讯拓扑,通讯模型,状态机以及消息分类,下一篇文章主要侧重于XCP命令的格式。

通讯拓扑

XCP 通讯是一种点对点的通讯协议,即同一时刻单个Master和单个Slave之间进行通讯,通讯都是由Master来发起的,Slave根据实际情况来回答Master的请求,Slave端同一时刻只允许同一个Master建立连接。但是,XCP协议也是可以支持网关的。

XCP_Topology

通讯模型

所谓的通讯模型指的是使用XCP通讯的Master和Slave之间的通讯方式,在XCP协议里边规定了支持三种通讯模型,标准型,块传输型(主块传输和从块传输两种),交替型。标准型指的是一问一答的方式,块传输则是多问一答,交替型比较特殊,指的是,被问的一方可以根据自己的实际状态延迟做回答(多问多答)。

接下来大家看一下下边4幅图,大家可以在看图的同时思考一下,它们分别对应的是哪种通讯模型,然后看看自己都分析的是否正确。

XCP_Com_Mode

上边4幅图从左到右对应的通讯模式分别是:标准型,主块传输型,从块传输型和交替型,你答对了吗?那么这4种通讯模型具体的使用场景是什么呢,为什么要分这4种模型呢。

  1. 标准型。同大部分CAN通讯协议一样,XCP首先支持一问一答的通讯方式,使用这种方式通讯的时候,上位机向下位机发起某个请求,下位机根据上位机的这个请求执行相应的动作,并适当的根据情况给予响应,上位机在收到下位机的响应以后才会发起下一个请求。这种方式被应用到大部分的XCP命令中。
  2. 块传输型。当一条CAN消息无法容纳一次通讯需要的全部数据的时候,为了减小交互时间,XCP设计给出数据的一方不停的将全部数据发送出来以后,接收方才进行一次回复,典型的应用场景为,XCP中的内存上传、下载、刷新命令。在这种传输方式下,因为一方要不停的发送数据给接收方,为了保证数据能够正确不丢失的传输,XCP定义了两个参数,块传输过程中两帧的最小间隔时间MIN_ST以及一次快传输所能使用的最大的块大小MAX_BS。
  3. 交替型。这种传输方式比较特别,在实际应用中使用较少。交替型传输意味着,收到数据的一方(Slave端)在收到Master发来的请求以后可以不立即响应,这个时候Master可以继续发下一条情况,从而在Slave端形成一个请求队列,Slave端可以根据自己的资源情况,当资源空闲时再去一一服务和响应请求。设计这种通讯模式的目的是考虑到有的ECU(Slave端)硬件资源有限,毕竟XCP是一种开发手段,在ECU软件设计中处于低优先级的服务,因此没办法及时响应Master发来的请求。

Slave状态机

Slave状态机是一个通讯协议中必不可少的一部分,它描述了使用通讯协议的时候,Slave有哪些状态,状态间是的互相切换规则是怎么样的。XCP在Slave端的状态机如下图所示。

XCP_Statemachine

XCP的状态机中只有简单的三个状态,DISCONNECTED,CONNECTED和RESUME状态。当系统启动以后XCP会根据当前的RESUME模式是否使能来判断进入DISCONNECTED还是RESUME。我们先来看一下大部分使用场景的RESUME模式关闭状态,RESUME模式我们稍后介绍。当XCP处于DISCONNECTED状态下,除了连接命令以外的其他XCP命令都会被XCP协议栈忽略,只有当协议栈收到连接指令以后,协议栈才会切换到CONNECTED状态,在这个状态下,协议栈可以响应和处理所有的XCP命令(所有的标定猜数都是在这个状态下处理的)。当处在CONNECTED状态下的协议栈收到断开连接的命令以后会退回到DISCONNECTED状态。此外,当协议栈中发生了严重等级为S3的致命错误的时候,协议栈也会从CONNECTED状态退回到DISCONNECTED状态。这些严重度等级对应的具体错误在XCP的规范中可以查找的到。

我们刚提到系统启动以后会先检查RESUME模式是否使能,那么什么是RESUME模式呢。从上边的状态图可以看出,如果要实现对系统的变量参数采集,上位机需要和XCP协议栈进行连接握手才能进行采集,其实在实际采集前的握手交互远不止这些,还有采集的变量列表的初始化(ODT/DAQ初始化),这些动作是非常耗时间的,而且需要上位机来发起,但是有时候我们需要实时的获取到ECU系统启动过程中的一些重要数据,那么在这种工作模式下,这些重要参数是没办法被采集到的。为了解决这个问题,XCP引入了RESUME模式,在这种模式下,ECU在上次运行的时候,上位机可以通知它使能RESUME模式,并把需要采集的重要数据的ODT/DAQ描述存储到NVRAM中,然后ECU经过一次掉电和上电的复位以后,在启动过程中,协议栈会检查到RESUME模式已经被使能,那么就会直接进入RESUME状态来不停的将ECU中的指定参数发送出来。值得注意的是RESUME模式跟DISCONNECTED模式有一个相同点就是,在这个模式下协议栈无法响应除了连接命令以外的其他命令。一旦收到连接命令以后,协议栈会进入CONNECTED状态,同时停止数据发送,等待正常的命令交互。

消息分类

不同的命令各司其职从而实现了XCP的协议,对消息进行分类有助于更好的理解和实现XCP协议栈。XCP的消息分为两大类:CTO(Command Transfer Object,命令传输对象)和DTO(Data Transfer Object,数据传输对象),顾名思义,CTO是指所有功能性命令的传输,DTO是指所有数据的传输。

CTO中又包含一种主发给从的CMD(命令),和四种从发给主的消息,RES(肯定响应),ERR(否定响应),EV(事件,在发生某些事件的时候,下位机用这种消息来通知上位机),SERV(服务请求,在某些情况下,下位机虚需要请求上位机做一些动作,那么它将通过这种消息来发起请求)

DTO中包含了一种主发给从的STIM(反向DAQ),这种消息跟我们前边文章中介绍的STIM和BYPASS功能使用相关,它用来大批量的向下位机发送数据。另一种DTO是DAQ,这种消息用于大批量的将ECU中的数据发送给上位机,也就是数据采集和测量用到的主要消息。

XCP_Message_Packet_Type

标签: Automotive Software 软件构架 汽车 软件 标定 测量 MCD CAN Calibration

评论(0)

暂无评论

欢迎留言

This template was modified by Edward