使用ControlCAN.dll收发报文功能实现诊断仪与硬件的UDS报文交互

背景：上位机使用ControlCAN.dll收发报文功能模拟诊断仪发送19 42故障问询报文，获取硬件故障信息。在此记录下程序实现过程中遇到的问题及解决措施。

1. 上位机一直在发送19 42服务问询硬件故障信息

原因分析：目前上位机模拟诊断仪与硬件的报文交互策略制定不合理导致cantest采集到的报文不连续，目前报文交互策略如下：
单开一个诊断线程，上位机程序一直判断是否接收到来自硬件回复诊断仪的报文，如果接收到的话就将报文数据储存起来。诊断仪需要发送的报文，包括回复硬件的报文都使用同一个函数执行。

策略调整：假设通讯正常不会超负载，不会出现报文丢失的情况，诊断仪发19 42问询硬件DTC状态后，等待硬件回复。硬件回复可能存在两种情况：回复单帧（无故障）、或者回复首帧（存在至少一个故障）。如果硬件回复单帧，诊断仪继续发送19 42询问硬件当前DTC状态（周期性问询），如果硬件回复首帧，诊断仪发送流控帧，等待硬件响应流控帧回复连续帧完毕后，诊断仪再继续发送19 42询问硬件当前DTC状态（周期性问询）。

2. 上位机接收硬件回复报文信息存在报文丢失的问题

按照上述调整之后的策略，第一次修改程序，cantest采集到的报文数据如下：

检查程序怀疑可能原因是正好没有接收到第一次硬件发送的响应19 42的首帧报文导致程序继续发送19 42问询故障状态。
正确的诊断仪与硬件的应答流程如下：

使用ControlCAN.dll接收报文函数获取到的硬件应答报文存在报文缺失现象：

策略调整：上位机程序应该保证连续帧的每一帧都获取到，如果中间存在报文丢失的情况，放弃这次问询，模拟诊断仪继续发送19 42询问当前DTC状态。但是这样子做还是没有从根本上改变报文丢失上位机程序获取不到但是cantest能够采集到的情况，将会导致一直获取不到完整的DTC状态。

问题解决考虑方向：研究ControlCAN.dll的接受报文接口函数，看为什么接收不到硬件发出来的实时应答报文。

分析采集到的cantest报文，硬件内部响应诊断仪的报文流程可能存在问题

目前存在两个问题需要解决的：（1）上位机模拟诊断仪与硬件UDS报文通讯的线程会丢失连续帧的报文数据；
（2）硬件回复连续帧第一帧失败可能会继续发送剩下的连续帧，导致上位机解析故障报文失败。

对于第一个问题，屏蔽掉其他线程，单独只开上位机模拟诊断仪与硬件UDS报文通讯的线程，发现能接收到硬件发出来的所有连续帧信息：

上位机读取到的硬件回复连续帧信息与cantest采集到的报文一致。

解决该问题的思路：考虑多个线程之间的资源分配问题。–待解决
怀疑是其他线程也在调用接收报文的功能，影响读取硬件与诊断仪的UDS报文交互接收报文数据采集。
为了验证上述思想，只屏蔽掉调用接收报文功能的线程，其他线程和硬件与诊断仪UDS报文交互的线程开放出来–测试发现能够接收到完整的连续帧报文信息。

3. 硬件停发连续帧响应报文

监控cantest报文发现，硬件停发连续帧响应报文。

监控上位机发出的报文，报文停止在流控帧。

思考：为什么硬件停发连续帧响应报文？