一、背景
最近又开始做诊断了,发现配置22服务的接口时,有一个OpStatus参数,用来表征当前的操作状态,于是决定查一下这个参数的具体作用
二、为什么会有OpStatus 这个参数?
配置22服务时,通过不同的接口类型,22服务对应的Cbk 会存在三种函数实现方式
- 当 DcmDspDataUsePort 配置成USE_DATA_SYNCH_CLIENT_SERVER 或者 USE_DATA_SYNCH_FNC 时,函数实现如下
- 当DcmDspDataUsePort 配置成USE_DATA_ASYNCH_CLIENT_SERVER或者 USE_DATA_ASYNCH_FNC 时,函数实现如下:
- 当DcmDspDataUsePort 配置成USE_DATA_ASYNCH_CLIENT_SERVER_ERROR或者 USE_DATA_ASYNCH_FNC_ERROR 时,函数实现如下
这三个函数实现上看,2与3的区别在于是否能指点NRC码,现在我们重点说说OpStatus
1. Dcm_OpStatusType
AUTOSAR_SWS_DCM描述如下
单单看这个不好理解,需要结合22服务接口返回值的描述来看,如下图
这里读DID的RTE值描述了两种返回值,当RTE接口返回DCM_E_PENDING时,Dcm_MainFuncion在每个调度周期都会访问该服务的RTE接口,就是可以将22服务这种短服务转成一个长服务,以应付特殊情况下22服务读取数据时间过长的问题
三、可以利用这个参数实现什么?
首先,我认为,上面关于ReadData接口的返回值应该少了 DCM_E_FORCE_RCRRP。因为就DCM_E_PENDING的描述来,直接上DCM只是挂起,并不会发出响应数据。但是我认为,这里是需要发78出去给Client的,以避免对方超时收不到数据。
如果是支持RCRRP的话,RTE接口通过反馈RCRRP,这样DCM发出78,后面DCM将OpStatus切换成
DCM_FORCE_RCRRP_OK,这样Rte接口也能检测到78已经发出,在根据情况看是继续发78还是返回肯定应答
我目前使用的ETAS工具,是不支持RCRRP这个功能的,我通过修改静态代码增加了这个功能,下图是关键的实现点以及静态代码修改处
仅做了对22服务的检测