这一篇只简单的理一下，Autosar架构下，Can报文的收发流程和参与的模块
一、参与模块
我们知道，报文的种类有应用报文，网络报文，诊断报文和xcp报文，它们的收发有什么区别呢？下面看一下不同报文的收发参与的模块（从Can驱动向上依次）
应用报文：CanDrv – CanIf – PduR – Com – Rte
网络报文：
诊断报文：CanDrv – CanIf – CanTp – PduR – Dcm
xcp报文：CanDrv – CanIf – xcp
【网络报文的没理太清楚，写错了再产生误导，理清楚了再单独写一篇；这篇只介绍应用报文的收发】
二、Can报文收发流程（应用报文）
1、接收
1.1 各模块参与过程
Can接收功能需要使用到通知（Indication）服务，在Autosar架构中，由（Bsw调度周期性的Can_MainFunction_Read），现项目是Can_17_McmCan_IsrReceiveHandler放在Can中断中，会根据Rx的缓冲区类型来选择处理函数，但是不管什么类型的缓冲区，最终都会调用Can_17_McmCan_lRxExtractData将数据从缓冲区中读出来，然后将消息对象信息分配给RxMailBoxInfo【RxMailBoxInfo中包括CanId，对应的Hoh，和ControllerId】，Rx Pdu信息分配给RxPduInfo【RxPduInfo中包括 指向Ddu数据的指针*SduDataPtr，Sdu长度】，最后调用CanIf_RxIndication通知CanIf向上传输，调用关系如下图
1.2 接收报文在com层的处理
接收报文在com层，将i-pdu拆解成signal，具体如下：
Step 1 ：
由PduR调用Com_RxIndication向上通知Com层接收Pdu，
在Com_RxIndication中：
1、调用Com_ResetUpdateDMTime，为基于I-Pdu的监控重置接收截止时间监控定时器（DM）{有ub的signal/signal group且ub不为1的除外}
2、调用Com_RxPduHandle
3、如果ComIPduSignalProcessing配置为immediate，则调用Com_IndicationProcess立即处理pdu接收，带有ub的signal/signalgroup检查ub是否为1，不带ub的signal/signalgroup直接继续处理，调用Com_SignalRxIndication / Com_SignalGroupRxIndication
4、signal处理 ： Com_SignalRxIndication中，对信号类型为COM_UINT8_N和COM_UINT8_DYN另外处理，不为此类型的调用Com_RxSignalHandle ；
①、字节序转换：Com_RxSignalUnPack；
②、信号值有效判断 ：若使能了信号无效通知，则调用ComInvalidNotification函数，若没有使能，则调用Com_RxSignalReplaceHanlde将信号值替换成原始值；
③、过滤条件判断；若全通过，则第6步
5、signalgroup处理 ： ①、signalgroup信号值有效判断，若无效则调用通知函数；
②、过滤条件判断；若全通过，则第6步
6、调用ComNotification函数，此通知函数为Rte_COMCbk_signal/signalgroup_name，调用Com_ReceiveSignal/signalgroup，将数据通过Rte向上传输；
2、发送
2.1 在com层的处理
对于发送报文在com层，将signal封装成i-pdu调用Pdur_ComTransmit向下传输，那在com层都做了哪些处理呢？（周期发送报文）
在SWC_EcuMon，通过周期调用的发送处理函数中，调用Rte_Read_xx将Signal数据从xx中读出，需要过E2E（信号组中带有checksum和alive counter）的信号组调用对应的E2E_xx_signalgroupname处理函数，最后调用Rte_Write_com_(signalgroupname)将读出的数据和E2E中的counter、checksum值通过Rte传入com层（调用Com_SendSignal/group）
Step 1 ：
上层的SWC通过Rte调用对应的Signal/Signal Group接口（Com_SendSignal/group），
在Com_SendSignal中：
- 信号发送模式处理 Com_TxSignalTMHandle
- 更新发送信号的buffer，检查信号value是否更新
- 第2步信号值更新后，将Tx Signal 打包到Tx buffer（字节序转换和符号扩展在这一步中）
- set update bits
- 添加信号的发送属性以及选择报文的发送模式
在第3步时已将更新signal value到Com_TxIPduRuntimeBuff[COM_TXIPDUBUFF_SIZE]缓冲区中
Step 2 ：
周期调用的Com_MainFunctionTx中：
- DMCnt计数（超限监控），超时后调用Com_TxDMTimeOutNotification
- 报文的发送模式确认（TMS）
- 调用Com_MainFunction_SendPdu，发送pdu
在Com_MainFunction_SendPdu中：
在调用PduR_ComTransmit之前可以配置ComIPduCallout，在Callout中实现一些特殊功能
- Com_TxIPduRunTimeState[txIpduId].Transmiting = TRUE; // 在调用PduR_Transmit之前设置发送标志，避免在设置发送标志之前出现TxConfirmation
- 调用PduR_ComTransmit
- 第2步返回E_OK后调用Com_ClearTxIPduUpdates清除该pdu所有信号和信号组的UB位
PduR_ComTransmit --> CanIf_Transmit --> CanWrite
三、Deadline Monitor
超时属性属于信号属性，但数据的传输是通过i-pdu报文形式，所有，COM的超时监测是以报文为单位监控的，但是同一条报文中又有不同的信号，信号的超时值又可以配置不同的，报文的超时时间怎么算？
报文的超时值 = 信号中最小的超时值
报文中各信号的超时值 = 报文的超时值
1、发送超时
1.1、发送超时 ：从启动报文发送到发送确认之间的时间。
另外规范规定：
1、对于传输模式DIRECT和MIXED，应确保配置的重发请求次数能在配置的周期内发送完成，
2、对于ComTxModeMode DIRECT and ComTxModeNumberOfRepetitions > 0的，在ComTxModeNumberOfRepetitions + 1成功接收到发送确认后，AUTOSAR COM模块取消发送截止时间监控定时器。如果在comtxmodennumberofrepetitions + 1次确认后定时器被取消，则表示传输成功，然后将传输确认发送给用户(如RTE、SwCluC)
也就是说，如果对ComTxModeMode配置了DIRECT和MIXED，且ComTxModeNumberOfRepetitions > 0，那么在超时时间之内就必须把重发次数发完，否则就会上报发送超时；超时事件发生后，com层会调用Com_CbkTxOut通知users
2、接收超时
2.1、接收超时：在规定时间内没有接收到报文
1、ComFirstTimeout （首次接收超时）
The transmission deadline monitoring timer shall be started with the configured ComFirstTimeout value if the timer is started for the first time after a (re-)start of the transmission deadline monitoring service for this I-PDU, otherwise the timer shall be started with ComTimeout value.⌋
仅在下列场景中：初始化后；报文所在的功能组重新启动； 报文所在的功能组的接收超时重新启动。
首次超时时间一般配置的时间较长，
2、ComTimeout（正常接收超时）
不在上述场景中的其他正常情况下的超时监测时间
对于同一I-PDU中所有没有更新位的信号和信号组，AUTOSAR COM模块将使用所有这些没有配置更新位的信号和信号组中最小的配置非零超时参数(ComFirstTimeout, ComTimeout)对l-PDU进行接收截止时间监控。
如果对带有更新位的信号配置了接收截止日期监控，则AUTOSAR COM模块应对每个带有更新位的信号/信号组执行单独的接收截止日期监控。
四、最小延迟时间
为防止总线的负载率过高，用户可以为发送的 Pdu 配置最小延迟时间。配置了最小延迟时间后，在该时间内，最多只能有 1 帧报文发送到总线上。如果在该时间内有多于 1 次发送请求，则后续的请求会被退后到最小延迟时间之后发送。该时间仅对相同 PduId 的发送报文起作用，不同 PduId 的报文之间无最小延迟时间的限制。
1561
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
