【AUTOSAR案例分析】SOME/IP通信测试，MCU接收SOC某一条Event A丢帧长达1s的时间

目录

一. 背景

二. 排查过程

三. 结论

---

一. 背景

ECU的内部通信使用SOME/IP进行交互，在实车测试时发现，SOC有一条SOME/IP Event 100ms发送给MCU，但MCU段的会出现偶发连续1s没有接收到该Event，影响业务逻辑的执行

二. 排查过程

1. SOC给MCU发送的Event A数据中的结构体有一个Counter，每发送一条自增1，MCU 20ms读取并打印Counter值，出现问题时，发现MCU有1s时间打印的Event A的Counter值没有变化，恢复之后Counter存在几十的跳动

初步分析：

• MCU能定期进行log打印，说明MCU的任务调度没有卡滞，说明和MCU的负载没有关系
• 如果是MCU的ETH底层的DMA接收BUFFER大小不够，那么应当只会出现概率丢1帧或者几帧，不会出现连续丢帧1s的情况，所以也和MCU的底层接收能力没有关系

2. 将MCU和SOC通讯的以太网数据通过Switch的镜像功能抓取出来，发现该Event对应的服务订阅正常，出现问题时刻，该Event正常发送

初步分析：

• 通过查看该条服务的订阅交互，发现该条服务订阅正常，所以和该服务本身的订阅没有关系
• 分析丢帧的期间，发现SOC是1s offer该服务一次，丢帧的时间刚好为1s，并且恢复接收时，刚好是下一次该服务重新订阅完成，所以和该服务的SoAd的状态有关，该服务的SoAd状态可能会受其他SOME/IP的行为影响
• 再次分析log，发现每一次出现问题的前后，都有一条非出现问题的服务的Negative Ack

• 排查出现问题时刻的SOC的SD（服务发现）的报文，发现某一时刻SOC发送的SD报文的Session id出现翻转的问题，正常其Session id应是连续递增的，如下图所示，SOC发送的两帧SD报文的Session id出现了翻转的问题

• 查看AUTOSAR文档，确认当Session ID没有增加，并且Reboot Flag为1时，就当作检测到通讯reboot，检查到reboot之后，对于客户端应像处理停止订阅那样处理，对于服务端，应当像处理停止订阅那样处理，所以就会导致其他所有的服务对应也被停止，对应的SoAd状态也被关闭（需重新订阅后恢复），所以就出现了虽然SOC一直在给MCU发Event A，但是由于SOC出现了session id错误，但是和MCU其他的服务的订阅状态其实已经被停止了，这时候虽然MCU底层接收到数据，但是不会给到上层处理，导致SWC出现所谓的丢帧现象，在大约1s后，SOC提供服务，MCU重新进行订阅，这时候又能够接收到Event A了，所以就是丢帧1s的现象

三. 结论

需要SOC修复Session ID回退跳变的问题