CCP协议（CAN Calibration Protocol）
CAN标定协议，基于CAN总线的标定协议
XCP协议（Universal Measurement and Calibration Protocol）
通用测试标定协议
可以应用在许多总线上：
XCP on CAN
XCP on Ethernet
XCP on FlexRay
XCP on USB
XCP/CCP主要应用于控制系统的开发和测试
XCP/CCP使用者为control system或mechanical engineers
XCP/CCP也广泛应用于system verification和testing
如果不用XCP/CCP，那么在ECU的软件开发中，将非常频繁使用C-code编译器和debugger。
通过XCP/CCP协议，配合A2L文件，可以直接在软件上更改某些参数，执行器就会给相应的反馈。
例如我们以前做一个单片机板子，如果想要修改里面的程序的话，需要先修改代码，再进行编译调试，生成hex或S19文件，再将程序烧写进单片机中，才算完成程序的修改。但是对于复杂的ECU来说，标定时是需要经常修改各种参数的，如果每次修改参数都需要编译调试生成再下载这一系列步骤的话，是非常影响工作效率的，所以使用CCP和XCP进行标定是非常便捷的。
CCP与XCP的优点
1、当ECU运行的时候，可以实时记录ECU内存中的变量。
2、可以具有真实物理意义和单位的数值来直接读写ECU变量，比如RPM、温度、开关等，而不是以原始的字节、位来读取。
3、实时改变ECU内存中的变量值，测试中实时改变ECU行为和性能，而不需重新编译ECU程序。
4、标定过程中，数据记录功能可以获取和记录全面的数据。
一、CCP的介绍
CCP主要功能
CCP全称CAN Calibration Protocol（CAN标定协议），是ASAM标准的组成部分，属于ASAM MCD1a规范标准。
CCP协议主要可提供以下功能：
1、随机读取ECU中RAM和ROM数据
2、测量数据采样
3、标定数据采样和传输
4、同时处理多个ECU系统
5、F1ash编程技术
CCP通信方式
CCP协议采用主从通信方式，具体又可分为两种：
1、查询（Polling）模式
2、DAQ（Data Acquisition Command）模式
在详细介绍CCP的通信方式之前，我们需要先了解一下CCP的系统结构。
如下图所示为CCP系统的整体架构，标定系统和各个ECU通过CAN总线连接。
下图是CCP系统结构：
从CCP系统内部具体结构可以看出，CCP系统结构主要由主设备MCD系统和电控单元ECU构成，其中ECU内部的CCP驱动程序又由命令处理器和DAQ处理器组成。
命令处理器主要是处理查询模式，是由标定系统主设备给命令处理器发出一个CRO的命令，ECU接受到之后再反馈响应给标定系统。
DAQ处理器主要是处理DAQ模式的，DAQ模式不需要主设备请求，每隔一段时间它会自动将ECU里相关信息传到测量与标定系统中。
二、XCP的介绍
XCP----标定和测量应用的焦点
Andreas Patzer（Vector Informatik，恒润科技提供译稿）
针对多种传输层和应用的协议
现代汽车系统中加入了越来越多的安全舒适性电控功能。虽然ECU的数量得到了控制，但是这就意味着要增加单个设备的复杂度来补偿功能的增长。XCP通信协议为这些分布式系统开发过程的合理化做出了重要的贡献，其主要任务包括实时地测量和标定ECU内部变量。该协议继承了CCP，它的一个巨大优势就是与物理传输层无关。
在当前，汽车控制模块中的变量数目超过1万的情况已经不足为奇了！在车辆的控制中有众多的动态过程需要控制，而ECU标定的主要任务就是优化这些控制算法。例如针对PID控制器，标定其比例、积分和微分环节时可能产生不计其数的变化版本（图1）。因此，就需要寻找到一个在稳定性、速度和动态特性方面足够好的结合点。这些可以通过实时读取和更改变量来实现(图2)。
图1 PID控制算法优化
图2 使用图形化标定和诊断工具CANape优化PID控制器
为了控制ECU标定的时间和成本，工程师和技术员通常会依赖可以灵活读写变量和内存的强大的工具和标准。为此，在90年代出现了CAN标定协议(CCP)，当时CAN总线是汽车中唯一的主流总线。CCP后来被指定为一种交叉OEM标准。然而，随着汽车电子的持续发展，其它总线系统诸如FlexRay、LIN、MOST等也开始成为主流。但是，CCP仅限于CAN网络应用，所以在其它潜在领域的应用局限日益增加。这样就导致了其后继协议XCP的出现。
通用的标准协议
与CCP一样，“通用测量与标定协议”(XCP)也是源于自动化和测量系统标准化协会(ASAM)[1]，它在2003年被定为标准。其中的“X”代表可变的和可互换的传输层。XCP通过双层协议将协议和传输层完全独立开，它采用的是单主/多从结构。根据正在讨论的不同的传输层，XCP协议可能指的是XCP-on-Can、XCP-on-Ethernet、XCP-on-UART/SPI 或XCP-on-LIN，如图3所示。
图3 传输层和协议层的隔离使得XCP可以利用大量的硬件接口
XCP主设备可以和不同的XCP从设备同时通信。这些XCP从设备包括：
为了满足作为针对大量不同应用的通用的通信解决方案的挑战，ASAM工作组强调了下列XCP设计准则：最小的资源使用（包括ECU中的RAM、ROM和必需的运行时资源），高效的通信，轻松实现XCP Slave，需要较少配置工作的即插即用性能，较少的参数，以及可伸缩性。
可互换的传输层
XCP可以在不同的传输层上实现同样的协议层。这是一种通用的测量和标定协议，可以独立于所使用的网络类型而工作。目前，ASAM已经在标准中定义的传输层包括：XCP-on-CAN，XCP-on-SXI(SPI,SCI), XCP-on-Ethernet(TCP/IP and UDP/IP)，XCP-on-USB和XCP-on-FlexRay。最后命名的版本(XCP-on-FlexRay)是协议家族中的最新成员，它早在2006年就产生了。XCP-on-FlexRay的一个特别的技术特征是动态带宽控制。测量、标定和诊断工具（MCD工具），比如CANape，可以识别可用带宽并能够非常高效地将其动态分配到当前的应用数据通信中。这样XCP通信的可用带宽就可以得到最理想的使用，并且不影响正常的FlexRay通信。
正在为将来考虑的其它方案包括XCP-on-LIN；如果有充足的客户需求，则也可能包括XCP-on-K-Line或XCP-on-MOST。由于支持广泛的传输层，使得从开发阶段的宽带（比如Ethernet或USB）方案移植到批量生产阶段的CAN接口方案变得十分简单。
一主多从概念
测量和标定系统承担了XCP主设备的角色，ECU作为XCP从设备工作。主设备和从设备的通信是通过集成在其中的XCP驱动程序来实现的。对于每个从设备都有一个ECU描述文件；这些文件规定的信息包括：（符号）变量名及其地址范围分配，数据的物理意义，使用的校验方法。XCP主设备可以从A2L描述文件里读取所需的全部信息。
XCP通信使用“命令传输对象”(CTO)和“数据传输对象” (DTO)来区分（主从通信）。XCP主设备可以在总线上向ECU通过CTO发送命令。ECU会在执行完请求的服务后以同样的途径进行应答。CTO会提供：CMD（命令）, RES （响应）, ERR （错误）, EV （事件） 和 SERV （服务请求处理机）。数据传输对象DAQ（数据采集）和STIM（激励）用于以事件驱动方式从内存中读取测量变量或者向XCP从设备的内存中写入变量值。
图4：XCP主设备和XCP从设备之间的通信
从汽车总线到标准PC接口
PC平台几乎只用作测量和标定的主设备。为了直接连接到汽车总线系统，比如CAN、LIN、 FlexRay、MOST 或 K-Line等，通常会为PC机安装一个或多个硬件接口。此外，XCP主设备也可以利用标准PC接口，例如以太网、USB和RS232等。当然，在这些解决方案中不会增加额外的硬件接口成本。带调试接口（JTAG，TRACE等）的测量和标定系统以及内存仿真器都可以通过这种方式实现。原则上，标准PC接口非常适合于连接存在于不同总线系统间的网关，比如FlexRay-on-Ethernet就可以很好地实现此功能。最后，在很多开发和测试计划中会使用到传统模拟和数字I/O通道，这些通道尤其会涉及时间-关键测量。
使用XCP的一个显著优势就在于这样一个单一标准协议满足了所有这些应用需求。如果没有XCP，就需要为每个通信通道定义一个专用的驱动，然而在同时使用多种驱动时需要考虑性能损失，此外还会增加出现不受欢迎的相互影响的风险和不稳定性。
通用、可扩展并节约资源
一个，并且是同一个XCP驱动代码可以应用于所有的通信过程。它可以用于从低端控制器和接口发送仅仅几个字节的数据，比如集成了串行接口的8位处理器。同样的代码也可用于通过高速的网络（比如以太网）使用32位处理器发送兆字节量级的数据。XCP驱动是由强制功能和可选功能组成的，驱动的大小可以根据可用的ROM/Flash的大小进行调整。在ECU中，通过是否具有高数据吞吐量或低处理器负载和RAM尺寸来表征资源用量。
对于总线负载，主要考虑传输信号的数目相比总线带宽。总之，XCP驱动容易实现，而且仅需要很少的几个变量。
事件驱动的周期性数据采集
ECU在离散的时间间隔上运行。可以将这样的一个时间间隔长度固定（比如10ms），或者定义其依赖于某种事件（比如发动机转一圈）。在固定时间间隔的情况下，时间片的结束是以定时器的溢出来标记的。从广义上讲，这种定时器溢出也是一个事件。ECU的任务是在一个特定的时间片内完成所有的计算和控制任务。为了从XCP从设备中获取相关的数据信息，使用了XCP协议中的DAQ机制。在该机制中，在测量开始前XCP主设备会先通知XCP从设备：特定的事件发生时需要测量哪些信号。如果现在事件发生了（如10ms定时器溢出），XCP从设备就从内存中读取这些先前定义的数据，并且将他们拷贝到受保护的RAM区，然后通过消息的方式发送给XCP主设备。这保证了数据值来自同一事件循环并且是相关的。
XCP主设备接收带有时戳的数据并且将其保存在相应的测量文件中。时戳要么通过XCP从设备作为数据发送，要么分配到消息中通过硬件接口（比如CANcardXL）发送。在测量文件中，所有数据参考XCP主设备的时间基准进行同步，然后被进一步处理，例如在一个统一的时间轴上对测量数据进行可视化显示（图5）。这就允许在一张图中一致地显示不同XCP从设备的多个数据通道。
图5 在同一个时间轴上显示不同信号源的各种信号
除了前面已经提到的XCP相对于CCP的优点，XCP还支持所谓的冷启动测量和用于循环数据采集的任务的内部ECU时戳。在冷启动测量中，可以配置ECU让它在被激活后就立即周期性地发送数据，而XCP主设备不需要明确地初始化该功能。如果使用了内部ECU时戳，该时戳就不是在测量和标定系统中与后期评估相关的数据接收时间了，而是在XCP从设备中数据被创建的时刻。这样就消除了由于传输延迟而引起的不确定性（比如在总线带宽不足或者高负载情况下都会产生）。
优化特性曲线和特性图
除了基于数学模型的控制算法，ECU还要使用由离散插值点组成的特性曲线和特性图。为了达到预期的系统行为，通常通过试验方法（比如台架试验）建立和优化这些特性值表。A2L文件是用来描述测量变量和标定参数的。描述的选项覆盖了从简单标量参数到复杂数值表的范围。其中，描述内容包含了数据类型、原始值和物理值间的转换规则、特性map图的存储方案以及更多的功能。Vector Informatik公司提供的CANape及类似的高性能标定工具可以在屏幕上通过图形图表或数值表格的方式清晰地显示特性曲线和map图。
使用CANape和XCP进行快速原型
在ECU开发过程中，经常会频繁地将重要功能导出到外部仿真系统，这样可以花最小的代价来计算这些功能。直到仿真模型中的算法达到一定的成熟度，开发者才会从这些算法生成代码，这些代码可与其它ECU代码一起编译并烧写到ECU中。然而，在此之前，可以使用一种被称作“旁通”的技术（该技术耦合了真实ECU及其模型），通过旁通可以在开发初期不依赖硬件进行测试和优化工作。
在使用XCP的旁通技术中，XCP主设备使用DAQ从ECU中读取数据，将这些数据作为输入值发给模型并且使用STIM将模型返回的结果发送回ECU。值得注意的是，使用运行MCD工具CANape的普通PC机平台就足以满足旁通和建模的要求。这是个好消息，因为基于特殊实时硬件的解决方案可能会贵好多倍，而且在开发部门中这类设备也可能为数不多。CANape作为一个高度优化的XCP主设备，可以同时处理与真实ECU的通信和与在PC上运行的模型之间的通信（图6）。ECU参数和模型参数都可通过CANape和XCP进行标定。
图6 旁通：使用标准PC和CANape作为测试系统
通过XCP进行flash编程
XCP同样为进行ECU编程的用户提供了便利。ECU flash内存中的数据只能使用特殊的预定的flash程序进行改写，这些预定的程序也必须驻留在ECU中。原则上，可使用两种方法：第一种方案，flash程序被永久存储在flash中；首先，这样会浪费内存，其次会遇到交付车辆的安全问题。第二种方案，在需要重新编程的时候，仅使用PC工具通过XCP将flash内核下载到微控制器的RAM中。除了包含用于擦除flash内存和重写数据的flash程序外，flash内核也包含自己的总线和SCP驱动，它们用于通过总线接口与PC工具进行通信。
总结
XCP是一种标准而通用的有很多合理化潜力的应用协议。它不仅用于ECU开发、标定和编程；也用于在原型开发中集成需要的测量设备、功能开发中的旁通以及在测试台上进行的SIL和HIL过程。对于通过微控制器调试接口（例如NEXUS等）快速访问内部数据，通信是在专用硬件上进行的，不会出现故障。该硬件完成NEXUS到XCP-on-Ethernet的通信转换。这样带给用户的好处是不依赖于专用解决方案的工具生产商，并且可以重用组件。
Vector Informatik公司为用户提供了免费的驱动用于建立XCP从设备，该驱动可以从其公司的网页上下载[3]。从1996年就作为ECU标定工具出现的MCD工具CANape，一直以来都作为XCP主设备并按照最新的XCP标准进行不断地升级，这也得益于Vector积极参与ASAM工作委员会。CANape是市场上第一个具有XCP-on-FlexRay接口的工具。在第一辆FlexRay量产车BMW X5的开发过程中，这成为让BMW工程师决定在标定减震器控制系统时放心使用Vector的XCP协议栈和CANape的一个重要因素。
