硬核:汽车标定--多周期测量显示异常

xiaocheng

目录

1.问题现象

2.数据流分析

3.代码分析

3.1 AllocDAQ

3.2 AllocOdt

3.3 AllocOdtEntry

4.根因分析及解决方法

4.1 根因分析

4.2 解决方案

1

问题现象
在手撸XCP代码时， DAQ的实现是一大头痛的事情。最初单周期实现还好一点，特别是当出现了多周期的情况时，就出现了如下现象。


      解释一下

     为了测试XCP协议栈，我的算法为：Mea#i = Cal#i (i = 0-20)。

     当我选择所有观测量均通过10ms的周期进行上传时，数据显示没问题，即Mea10[0-9] = 10，Mea11[0-9] = 11；但是当我以1ms周期观测 Mea10，10ms周期观测Mea11，出问题了；如上图所示，本来应该都为11的，但是显示了一些我看不懂的数值。

     首先想到的是Slave拿数据拿错了，为什么会拿错呢？那肯定是ODT描述的element对应地址有问题。所以我们先来看看数据流，有图有真相。

2

数据流分析

当有两个daqlist的时候，CANape在动态配置时顺序如下：AllocDAQ(分配2个daqlist)、AllocOdt(给两个daqlist分配好odt)、AllocOdtEntry（给2个daqlist的odt分配好entry），并不是之前我理解的每一个daqlist分配好odt和entry之后再处理另一个daq，具体看如下log截图：


分配完毕之后再设置daq指针，往该地址里写相应的测量量的数据，如下
3

代码分析

     既然是ODT地址问题，那我们就从DAQ变量分配的地址开始查起来；我们根据XCP标准推荐的DAQ配置时序开始：



从AllocDaq、ODT、ODT Entry开始查起来3.1 AllocDAQ

上位机通过指令(0xD5)告诉ECU现在需要分配两个Daq List：


       这里会给DAQ分配一个buffer，如下：


编辑


编辑

       调试发现分配了两个DaqList，这里没问题；
3.2 AllocOdt

通过分配ODT（D4），数据流如下：


这部分具体代码如下：

代码行数	作用
831	odtCount表示这个DAQlist有多少条odt(可以想成多少条报文)，所以就是DAQ列表的大小
834/5	给PID赋值，同时给下一个DAQlist的首个ODT的PID赋值
837	将xcp_dyndaqodt[pos]的首地址赋给当前daq的odt
839	在动态daqbuffer的Odt位置加1；
840-844	给odt分配odtcount
845	给当前daq分配状态
846	给daq配置时序分配处于odt配置状态

       完成之后配置结果如下：



     这里发现第一个odt和第二个odt的地址不止8个字节（一帧报文），这里可能有点问题；

      0x70003fe8对应的是动态daqbuffer的首地址：


编辑

      找到该地址看里面的数据如下：


编辑

     发现数据存放并不是连续的，而是直接跳了24个字节；怀疑这里应该存在问题：看代码中，只是对Xcp_DynDaqOdtPos进行了加1，但是从log来看的话，


编辑

      应该是给daq0分配了6个odt，然后再给daq1分配了3个odt；如果只对位置进行加1的话，也就是Xcp_DynDaqOdt[pos+1]的地址为当前daq的odt的下一个odt的首地址；那么第二次给daq1给配3个odt的时候，使用的地址就为[pos+1]的地址；这样就把daq0的第二个odt给覆盖了；

      但是还是没能找到在代码什么位置给赋值，在allocodtentry函数里给Xcp_DynDaqOdt里写数据（每一条分配一个地址），包括地址和entrysize：





     很明显这里面只有6个odt（正确应是9个），第二个odt里面放的地址是70004018，如下：


编辑

    正常情况下，第二个odt里应该放置的Xcp_DynDaqBuffer[1]的地址；也印证了之前odt被覆盖的猜想。
3.3 AllocOdtEntry  

      上位机通过指令ODT ENTRY（D3）分配Entry，这里就是给每一帧数据分配几个数据，还是接着上面的，第一帧可上传7个字节的数据，那么如果每个数据的大小均为4个字节，就只能上传1个数据加上下一个数据的前三个字节，因此ODTENTRY为2；那么第二帧接着上面的就可以上传第一帧未传完的剩余一个字节（1byte）、第三个数据（4byte）以及第四个数据的前两个字节（2byte），所以第二帧的ODTENTRY为3；以此类推。数据流如下：



     调试结果如下：



ODTEntry里面包含了entry的地址（需要上传数据的地址）、长度等，且ODTentry本身的地址是动态daqbuffer里的地址，即是说我们是通过将数据放到动态daqbuffer里，然后再上传。
4

根因分析及解决方法

4.1 根因分析

DAQ上传的具体线路：
首先，在AllocOdt这条指令下，将Xcp_DynOdtBuffer的地址赋给DAQ[x].odt[y]；然后在AllocOdtEntry，将Xcp_DynDaqBuffer地址赋给OdtEntry；    最后在writeDaq里将变量的地址写到给OdtEntry（Xcp_DynDaqBuffer）里，即在Xcp_DynDaqBuffer里存放实际测量量的地址、DynOdtBuffer存放的是odtentry的地址。由于在alloctOdt时覆盖了DAQ0的第2-4个ODT，所以会出现如下现象：



并没有一一对应。4.2 解决方案

那么修改代码如下：



数据显示正常：


编辑
哭了，注释一行代码，调试了一周。 还是当时设计时没有理清思路，给自己埋下了大坑。往期回顾：
1.汽车标定合集    汽车标定技术--XCP协议如何支持测量功能
    汽车标定文章合集
2.AUTOSAR合集    AUTOSAR OS概述（一）    AUTOSAR OS概述(二)    AUTOSAR文章合集3.汽车网络安全合集    汽车网络安全方案需求分析
    汽车网络安全渗透测试概述
    汽车网络安全文章合集
4.汽车功能安全合集

针对上述问题，您的汽车标定项目中遇到了多周期测量异常现象的问题，首先阐述问题的具体表现是必要的。根据您提供的信息，当使用XCP协议栈进行测试时，观察到某些数据在多周期上传时出现问题。这可能与DAQ（数据采集）模块的实现有关。

为了解决此问题，我们需要对涉及的代码进行分析。尤其是关于AllocDAQ和分配odt功能的代码块需要深入检查，了解如何实现周期性数据上传的具体过程。具体的解决方案可能包括优化DAQ模块的设计，确保在多周期情况下数据的正确采集和传输。此外，还需进行数据流分析，以确定数据在不同阶段的传输情况，找出潜在的错误根源。在深入分析后，我们将给出具体的解决方案并进行验证测试。通过调整相关代码和优化数据传输机制，有望解决多周期测量异常的问题。

suzuki

回复：

尊敬的同仁，

关于您所提到的汽车标定中多周期测量显示异常的问题，现对问题现象进行简要解释：

在手撸XCP代码实现过程中，DAQ（数据采集）模块的处理，尤其是在多周期情况下，确实可能遇到一些挑战。当按照您的算法设定，例如Mea#i = Cal#i (i = 0-20)，并在选择所有观测量以10ms周期上传时，可能出现数据异常。

针对此问题，我们需进一步进行数据流分析、代码分析以找出根本原因。在数据流分析环节，我们需要关注各数据节点的流动情况，检查是否存在阻塞或错误传递。代码分析方面，需重点查看AllocDAQ、AllocOdt及AllocOdtEntry等关键模块的实现，看是否存在逻辑错误或性能瓶颈。

问题的根源可能涉及代码逻辑、内存分配、处理速度等方面。解决时，可考虑优化算法、调整内存分配策略、提高处理效率等方案。具体的解决方案需要根据数据流分析和代码分析的结果来确定。

后续我们可深入探讨，寻找最佳解决路径。

谢谢！