汽车标定--XCP如何参与不同的开发阶段

lidenghui

目录
1.模型在环

2.软件在环

3.硬件在环

4.Bypassing分析

5.软件Debug over XCP
6.小结
在前面我们啪啪啦啦讲了一大堆关于XCP的一些基本概念，在使用上面还是做过XCP slave协议栈和做过ECU参数标定的开发人员接触得最多。

不过就目前接触到比较通用并且粗放的开发模式基本都是应用层模型生成代码后直接与基础软件进行集成，然后上HIL标定，最后上实车。

那么到底XCP除了上面两种，还会用在哪些地方呢？这里简单总结一句，在软件开发的各个流程环节，只要代码可以跑的地方都可以使用到XCP（只是看成本和是否有必要）。经过多方咨询后，现将XCP使用场景总结如下。
1.模型在环场景

MIL，全称Model-in-the-loop。这个对于模型开发的同学来说是非常熟悉的，模型代码，跑跑仿真，出来一个漂亮的曲线，开心下班。那么为什么还需做标定呢？因为某些公司想为我们提供全生命开发周期的解决方案，想在模型开发阶段就做实时系统的验证。我们在Mathworks官网搜索第三方标定工具，可以明显看到ETAS Inca和VECTOR CANape的身影，如下：


很明显，在Simulink的建模阶段，CANape或者Inca就开始为实时系统的验证做准备，详细分析如下：

1.模型开发阶段，控制器和被控对象均是由模型搭建，此时还没有生成代码。

2.CANape、Inca与Simulink合作，推出在模型中集成XCP slave的组件

3.标定上位机可直接与模型进行通讯，时间戳由上位机提供。

4.Simulink模型界面如下：

上述分析最后可总结成如下框图：



那么XCP可以在软件开发早期MIL阶段就接入到数据的标定和测量，在一定程度上模拟了实时系统，就不再像模型那样纯仿真那样，跑了半小时，实际模拟时长20秒。
2.软件在环场景
软件在环，即Sofeware-in-the-loop(SIL)，主要是在PC上验证测试simulink生成的代码，这个阶段需要进到SIL模式进行测试，通常是背靠背测试，如下图：



既然在模型阶段就可以介入，那么控制器代码已经生成了，肯定就有办法进行标定和测量。自然，第三工具闪亮登场。

用Embedded code中将模型生成DLL和A2L文件，然后嵌入到第三方工具提供的界面，开标。这种情况下，模型以DLL的方式运行在PC端，被控对象仍旧为模型，通过标定工具可以进行测试，这种场景模拟的是代码已经集成到ECU中。

参考模型如下：



参考链接：

https://cdn.vector.com/cms/content/events/2018/Webinars18/Vector_Webinar_CANape_MATLAB_Simulink___20180222.pdf

3.硬件在环场景

硬件在环，Hardware-in-the-loop这个肯定大伙儿就很熟悉了，一想摸鱼的时候就说我去HIL测一下数据。那么在HIL上XCP其实就很接近实车了，如下图所示：



4.Bypassing分析

在标定测量中的Bypassing功能，字面意思理解就是从ECU内部获取数据，在ECU外部的模块对数据进行处理，并将处理结果同步给ECU。

借用Vector一张很生动的图：



Bypassing的处理需要用到XCP中数据传输指令DAQ和STIM。从上图可以看出，数据在外部硬件处理其实是需要和ECU内部同频的，因此这里就需要使用到高端的ECU访问方式，Vector的VX1000和Inca的ES900此时站了出来。

还是老规矩，首先用图来让大家认识Bypassing系统：



在该系统中，很明显的就是A2L包含了两份：ECU和Bypassing，主要针对DAQ和STIM的测量量、通信速率等描述，保证ECU中Bypassing的算法后续感知不到bypassing的存在。

那么现在假设ECU中的控制算法A是一个比较稳定的版本，我这时候突发奇想开发出了该控制算法的升级版A'，但是为了不去搞重新集成的麻烦事情，我就想用bypassing来验证算法A'具体使用步骤如下：

1.ECU通过DAQ将数据x发送Bypassing硬件，

2.Bypassing协调器将数据传给算法A’进行处理，通常该算法在simulink模型中；

3.算法A’将计算结果返回给Bypassing协调器；

4.Bypassing硬件通过STIM将计算结果写回到ECU，覆盖掉算法A的计算结果

可以发现，通过bypassing的方式对时间要求是比较严苛的，所以通常都是使用ECU的debugging或者trace接口用于实现该功能，这个接口支持我们可以在VX1000使用手册中查询，同时还需要有一些POD的知识。

除此之外，Vector的VN8900提供了一个完整的实时精度的bypassing解决方案。如下所示：



综上，Bypassing功能主要用于快速对控制算法更新进行验证，不知道这块的需求多不多。
5.软件Debug over XCP
Debug over XCP，很明显就是通过XCP的相关指令进行Debug，这是在XCP协议1.5版本中提出的一种新的特性，为啥要提出这个特性呢？我们来思考两个场景：

1.当ECU已经安装到汽车，并且无法拆卸，此时出现软件bug，需要实车静态调试；

2.当ECU已经使用Trace\Debugging接口进行标定和高速测量，此时出现软件bug，需要使用debug工具进行调试

上述两种情况该如何解决？聪明的人类选择在POD和XCP协议添加该特性，因此出现了Debug over XCP。

针对情况1，如下连接即可：



针对情况2，如下连接即可：



6.小结

以上我们总结了XCP在软件开发不同阶段的不同切入方式，老外针对ECU的全生命开发周期的生态链可谓良心用苦，并且已经在汽车行业培养了众多的拥趸，ETAS不多说了，那一系想逃出来还有很长的路要走；Vector普惠大众，使用方便；

国产替代前途无量呀。

往期回顾：

1.汽车标定精选
万字长文：汽车标定技术--XCP概述
汽车标定技术--A2L格式分析
汽车标定技术--标定量与#pragma的趣事
汽车ECU标定的实现方式
英飞凌TC3xx-Overlay机制

2.AUTOSAR精选
AUTOSAR OS概述（一）
AUTOSAR OS概述(二)
AUTOSAR 诊断栈分析(一)
AUTOSAR 诊断栈分析(二):DEM
AUTOSAR诊断栈分析(三):DTC状态位

3.汽车网络安全精选
汽车网络安全渗透测试概述
汽车网络安全方案需求分析
汽车信息安全--常见车规MCU安全启动方案
车载信息安全场景概述

4.汽车功能安全精选

5.汽车虚拟化精选

    汽车ECU虚拟化技术初探(一)

    汽车ECU虚拟化技术(二)--U2A虚拟化功能

6.杂七杂八

    我为什么开始写技术博客

    Flash模拟EEPROM原理浅析

shuizhonghua

关于汽车标定中XCP的应用，以下是专业回复：

汽车标定中，XCP（Executable Component Protocol）广泛应用于不同开发阶段。在模型在环阶段，XCP可用于模型的调试与验证。软件在环阶段，XCP负责参数标定与软件组件测试。硬件在环阶段，XCP用于实时数据交换与ECU标定。Bypassing分析时，XCP支持故障模拟与诊断。软件Debug over XCP可实现远程调试与故障排除。总而言之，XCP在汽车软件开发各环节都有应用，只要代码可运行，XCP即可发挥作用，但其应用需考虑成本与必要性。

关于目前通用的开发模式，虽然应用层模型生成代码后直接与基础软件进行集成，然后上HIL标定，最后上实车的模式较为普遍，但XCP的应用不仅限于这两种场景。在软件开发的各个流程中，只要有必要且成本合理，都可以考虑使用XCP。

shuizhonghua

关于汽车标定中的XCP应用及其在不同开发阶段的使用情况如下：

目录：

一、模型在环阶段，XCP用于参数下载及验证，确保模型的准确性与实时性。

二、软件在环阶段，XCP实现软件模块调试与标定，优化软件性能。

三、硬件在环阶段，XCP支持实时数据采集、故障模拟与标定验证。

四、Bypassing分析阶段，借助XCP实现特定模块绕过标定功能分析。

五、软件Debug over XCP阶段，实现远程调试和故障排除。这对于软件的精细调试与问题解决具有关键作用。

六、小结：XCP在汽车电子开发中具有广泛应用价值，涉及软件开发全流程。在不同开发环节都能根据实际需求运用XCP进行调试和优化，但其使用应结合成本与必要性考量。随着汽车技术的不断进步，XCP的应用将更加广泛和深入。