随着车载以太网技术的快速发展，智能汽车也已经走进了千家万户，OTA无线解决方案也逐渐走进了大众的视野；实际上在车载以太网未出现之前，我们车上大多数使用的升级一般都是adb、U盘等不太方便的刷写方式，并且在车上是一种很神秘的操作（一般仅在4s店和主机厂使用），然后这种方式在保证安全性的同时，也限制了车载软件的发展，无法实现快速的迭代，提供给终端用户更多新奇的功能，因此OTA应运而生。CAN/CANFD/LIN刷写在近几年的车载ECU上也逐渐进行了普及（大部分小型ECU不带有ETH接口），也是由于这个原因，我把常规的CAN、CANFD、LIN、Ethernet刷写放在了一起，更加方便大家的阅读和学习，他们的目的只有一个就是实现远程的车载ECU的软件更新。
编辑
一、CAN/CANFD刷写
这也是我工作生涯中最早接触的车载ECU的刷写方式，并且不管是现在的CANFD、Ethernet相关的有感、无感刷写都是在它的基础上进行衍生，因此这里是相当重要的一部分，特别是对于刷写逻辑的说明。
编辑
一般来说，每家主机厂的刷写流程都是一样的，无论是基于CAN还是CANFD，其中的区别也就是底层协议栈的处理可能会有略微不同，不过刷写主要在应用层，对于学习和使用这块的人来说并没有太大的影响，因此就分享一次得了，大家有需求可以私信或者评论联系我。
这块介绍的逻辑也是我们日常工作中的工作顺序，首先是需求分析，搞明白刷写流程到底是怎么样的，已经梳理刷写过程的各类操作到底是什么；这块搞清楚后，接下来就是测试设计， 测试设计也是有一定的方法，如何让一个新手具备一块功能的测试用例设计保证功能的完整性，这个我们就要引入测试用例设计方法、需求点提取方法等手段来保证，这些实现后就是测试用例名称梳理和测试用例编写了。
最后就是CAPL（vTESTstudio）自动化开发，实际上对于这块的开发我们使用Python也是能够完全满足的，但是为何我还是选择CAPL呢？这就涉及到我们的测试平台化，如何最大限度的保证软件功能的完整性，这里我们不做过多的纠结。不过由于CAPL语言的局限性，因此想要开发出大家都能直接看到的测试脚本，需要我们前期进行完整的架构设计，以及嵌入平台化测试的思想，最大限度保证代码的可复用性，因此我们会从函数、模块、架构3个方面全面讲解。
二、Ethernet刷写
如果公司有DoIP刷写的话，那么你可能会经常听到有感刷写和无感刷写的谈话，有感刷写顾名思义就是我们常见的CAN刷写逻辑，也是在终端用户有感知的情况下进行软件的更新；而无感刷写就是在终端用户感知不到的情况，并且不影响车辆的正常使用的情况下进行刷写。因此在这一块，会重新引入无感刷写的流程，这是区别于CAN刷写的一个刷写流程。
三、路由刷写
路由刷写实际上是域控制器时代的产品（仅代表个人观点），由于域控制器继承了车上大部分的功能，而域控制器与小型ECU模块间为了建立一体化联系，并且引入了车载以太网，因此有了路由的概念，路由涉及到了CAN、LIN、Ethernet之间的数据转换以及信息交流；并且也涉及了刷写功能，这里我们也会进行介绍。
BootLoader刷写简要
编辑
原文始发于微信公众号（车载网络测试）：车载网络 – BootLoader刷写 – 总纲
编辑
编辑
编辑