如何进行汽车 CAN 总线开发？
/* 没想到随手写的一个回答上了推荐，等有时间时我会完善一下答案 *//*Revisions:20161007, 初次提交；20161011, 增加对第一句话的解释；20161012, 调整解释的位置
如何进行汽车 CAN 总线开发？/* 没想到随手写的一个回答上了推荐，等有时间时我会完善一下答案 */
/*
Revisions:
20161007, 初次提交；
20161011, 增加对第一句话的解释；
20161012, 调整解释的位置，叙述调整；
20161031, 增加回复回复的回复。
*/
我看了下所有的回答，看来国内熟悉CAN总线协议栈研发的工程师比较少。这可能和国内几乎没有Vector、EB、Mentor Graphics这样的第三方供应商有关，产业链上其实缺少了一小环Tier 2。
王博士 @Wang Yu说的内容没什么问题，但看起来有点学院派，所以我想以从业者的视角做一些补充。
已经有主机厂同行大致介绍了主机厂网络组平时与CAN总线相关的工作，因此这里仅介绍OEM以下的内容：
事实上王博士提到的“底层”，在汽车行业的Tier 1供应商中，是非常重要的一块儿，大多知名零部件供应商都会有专门的团队负责这部分模块的研发，比如Bosch为此收购了ETAS的团队（也因此ETAS现在虽然仍然在出售OS，但其中的核心代码是不出售的）。这个“底层”在Tier 1中一般会称做平台，如Visteon正在服役中的有Newton 2.0、Kepler 1.0等平台。同时也会有另一个团队进行下一代平台的研发，和IT圈的产品迭代其实挺像的。
补充一下，王博士的观点也没有错，对于应用工程师来说，底层本身是不需要投入过多关注的，就好像程序员一般不需要了解编译器开发团队的工作。（当然这个类比不够准确，与现在行业的状态其实不太匹配。）
而CAN协议栈，就属于上述（软件）平台中的一部分。CAN总线从驱动层往上，有一系列的软件模块，如果想了解最新的分层设计，可以参考AutoSAR中通信部分的文档。而王博士回答中所提到的工作只包含了驱动开发的前期内容，也就是使CAN总线“通”起来，但这个工作在CAN总线的软件开发中其实只是基础的准备工作，一个懂单片机的应届生可能也只需要一两周，就能实现一个能通信的CAN驱动，然而这个驱动在正式产品中是无法使用的。
在实际的商业化产品中，CAN驱动层也会包含一些复杂的策略，如各种异常的处理，以及性能优化。模块本身还会有可配置性和可移植性的要求，毕竟CAN驱动也是软件平台的一部分，可复用性是一个很重要的考量。
而从架构角度来说，在传统的OSEK/VDX架构下，CAN驱动以上就有交互层、传输层（或叫网络层）、诊断协议层、网络管理、标定、信号/报文/协议网关等上层基础软件模块，几乎每一个都有相应的国际标准来对应，是一个相当专业且门槛不低的行业子领域。也因此，除了知名的Tier 1公司会自己招募一个团队做软件平台以外，一些中小型公司往往会选择购买市场上的第三方基础软件，以降低研发成本。目前国际上知名的第三方供应商有上述提到过的Vector、EB、Mentor Graphics、ETAS、KPIT等，国内现在也有普华、恒润等公司在做此类业务。
对于车载ECU来说，Tier 1的研发大致可以分为系统、硬件/电子、软件、机械/结构几个条线。CAN总线涉及最多的是上文提到的软件条线。系统部分基本只需要与OEM的网络工程师及DRE做一个对接，定期沟通下信号需求、通信矩阵释放、样件提交、测试结果反馈等，真正涉及到技术的工作比较少。硬件部分基本都有现成的方案，主机厂的CAN节点企业标准中往往也会提供参考电路和元器件型号推荐，对于有经验的硬件工程师，通常不会出现设计电路有太多的物理层问题需要修改的情况，偶尔可能会有一些电压、斜率之类的小问题。结构条线一般不怎么会有专门与CAN总线相关的工作。
以上内容展开则太过繁杂，不是一篇回答能够全部涵盖的，因此仅作大致介绍，希望能够有所帮助。
——————————
这里得解释一下：第一句话是我之前随手写这个答案的时候，表达了工作到现在一直以来的一个感受。可能会让很多汽车工程师觉得被冒犯，这里先表示道歉。其实我没有冒犯的意思，之前写的太随意了，表达不够清楚。相信看到我这个答案的同仁们，很多都称得上熟悉CAN总线，只是之前我想表达的，是其中一个特定方面的熟悉。
其实我的意思是，我觉得国内汽车电子行业内，对CAN总线相关协议有深刻理解及开发经验的工程师的数量，相对于整体的研发规模，有点少了。
比如说，国内数万汽车电子软件工程师，用过CAN总线的十之六七，但知道CAN相关各个模块设计原理的，恐怕百不足一。
比如说，国内主机厂的网络工程师同仁们，对CAN总线相关的标准如数家珍，日常工作就是指导供应商们实现相关协议，对提交的软件进行测试与反馈。但又有多少人，去研究过这些标准背后的know how呢？拿网络管理举例，每家主机厂都会有自己的一份网络管理企业标准，描述了一个详细的实现机制。但是，网络管理的协议并不少，有国际标准如AutoSAR CanNm，OSEK Direct NM，有第三方供应商设计的机制如Vector NmBasic，有主机厂设计完善的完全可以当作一份标准的机制如GM GMLAN NM，Volvo Volcano NM，也有主机厂设计的只有较为简单的状态机如Nissan/Renault NDS中所定义的，甚至还有隔壁商用车所采用的J1939 NM，等等。这么多简单的，复杂的，主从的，多主的，其优缺点是什么？选择的依据是什么？不知道在日常工作以外，会有多少人会去进行调研和分析呢？恐怕绝大多数人，像我一样，只能说出一些泛泛的道理，而缺乏有力的实验和数据支撑，以及深刻的洞悉。
需要特别说明的是，由于术业有专攻，我所在的工程师岗位相对会更关注协议的原理和实现，但这并没有什么高下之分，只是行业内的分工不同。
说到know how，这里还想夹带一些私货，不喜欢的朋友可以跳过。
记得有次我去国内某自主品牌主机厂搬砖，看到实验室中几位工程师在用测力计测试一款进口车型的车门铰链的阻尼大小（这方面不太懂，不知道专业的说法是什么）。当时我就脑洞大开了一下。
众所周知，我们国家的工业技术从起步开始，到现在为止，逆向工程从未停歇。这很正常也很必要，是我们快速追赶发达国家的重要方法。但有时候我在想，其实我们的积累已经不少，是不是该多做一些正向的研发了呢？逆向工程虽然能让我们得到一个接近完美的策略或数据，但通过逆向，我们永远只能知道what和how，而无法知道why。拿CAN总线举例，很多软件工程师都知道一般当错误计数器累加到96的时候，CAN控制器就会报一个Warning，但有多少人知道这个数字为什么是96呢？
回到车门铰链阻尼的选择，我是外行，假如让我来考虑正向开发，那我可能会想到，这个实验需要做出所有合理阻尼范围铰链，然后招募不同年龄段、不同性别、不同人种、不同体型、甚至不同职业的人前来测试，并记录下他们的感受，形成一个数据详实的调查报告，再加上各种危险工况的考量，来确定一个合适的数值。当然这个想法过于复杂了，可能国外都没有这么理想化，但我想说，只有通过类似的正向研发，我们才能不陷入“宝马用20N，那我们就用20N吧肯定不会错”的研发惰性中（数字仅为举例）。
有些技术标准，国外一更新，国内就懵了，只能紧跟步伐，根本不明白国外为什么这么变更。非常希望这样的情况，能够通过我们的努力越来越少。
逆向只能追赶，只有正向，才有可能超越。
愿与怀有技术情结的工程师同仁们共勉。
——————————
@只是学电的 关于CAN总线映射到OSI的分层我不是特别了解，因为没有看过ISO/IEC 7498-1等标准。这里提供一些我个人的看法。
前两天正好看到了一个问题个人计算机里面包含网络7层协议的所有协议吗，每一层分别对应哪个部分？ - 计算机技术，其中@invalid s的回答讲得特别好。对于实际开发工作来说，了解七层模型几乎没有实质上的意义，而且我个人觉得即使是用于教学，以七层模型来做讲解也是很糟糕的做法，因为框架性的内容对于概念都还没建立起来的学生是非常苍白的，对产生感性认识毫无帮助。我比较倾向于在培训时从底层（物理层）开始讲起，多举一些例子，这样即使毫无基础也不至于听完一头雾水。OSI七层模型的学术价值可能更于高实用价值。
回到CAN总线，其实这个问题ISO是已经提供了参考的，在ISO 14229-1: 2013的Introduction中，有一个表格Table 1 — Example of diagnostic/programming specifications applicable to the OSI layers（其实一系列的标准里都有提到，且内容还不太一样）：
Application (layer 7) - ISO 14229-1, ISO 14229-3, further standards
Presentation (layer 6) - vehicle manufacturer specific
Session (layer 5) - ISO 14229-2
Transport (layer 4) & Network (layer 3) - ISO 15765-2
Data link (layer 2) & Physical (layer 1) - ISO 11898-1, ISO 11898-2
从ISO提供的信息可以看到，在具有诊断功能时，CAN总线对OSI七层模型基本都有映射。而单独考虑通信功能时，在ISO 11898-1: 2003章节7.1 Reference to OSI model中提到，CAN总线只对应了DLL与PY层。
我个人的理解：OSI七层模型中只有物理层、数据链路层是硬件来实现的（CAN总线线束、CAN控制器、CAN收发器及相关元器件），而其余的五层均为软件实现。
——————————
@Keith 很抱歉前段时间比较忙，回复晚了。
我是软件工程师，不了解硬件原理，因此只能告诉你我所知道的，而且不能保证完全正确。。
这问题还挺复杂的，我尝试做一下分解。
首先，ISO 11898-2: 2003中给出了CAN总线物理连接方式的建议图：
图是我自己画的，原图请参考标准。
可以看到，在预想的状态下，终端电阻与CAN节点（包含CAN硬件的控制器）是分离的，终端电阻处于线束两端的位置（这和终端电阻的原理有关，我不懂本质这里就不妄加说明了），标准也特意强调了这一点。
终端电阻的阻值是一个经验值，标准在7.5.2 Termination resistor章节给出了标称值120欧、最小值100欧和最大值130欧，同时也说明了，根据不同的拓扑、比特率和电压转换速率，偏离标称值是可能的，并且，在每个项目中测试一下其它阻值的适用性也是必要的。
而现在主机厂在设计CAN线束时，一般并不会把终端电阻做在线束上（这也需要主机厂的同仁来解释具体原因，推测和下文提到的电气特性或架构设计有关）。目前一般将终端电阻设计在电控单元的PCB上，参考电路如下：
这样分裂终端电阻设计的好处是可以通过一个参考电平稳定电压，降低共模干扰。
主机厂通常会在CAN节点企业标准中推荐这样的参考电路，一条总线上CAN节点的个数一般大于两个，而CAN总线又只需要两个终端电阻，因此就引入了终端节点和非终端节点的概念。
终端节点一般设计在线束的最远端，近似标准中CAN总线的物理连接方式，其它节点则设计为非终端节点。由此可知，终端节点上的终端电阻应为120欧，若为分裂式设计，则应为两个60欧电阻。而非终端节点通常使用一个较大的阻值（具体原理不了解，不知道是要模拟开路还是其它原因，但由于电阻是并联的，至少要保证加上非终端电阻后，总线间的等效阻值与不加之前相比近似相等），如1.3千欧 * 2。
因为我不怎么关心元器件BOM，目前唯一有印象的就是有项目采用过60欧 * 2和1.3千欧 * 2的典型值（500kbps的波特率）。至于9千多欧我没有见过，如果确实无误，那应该是主机厂出于电气特性需要所计算出的非终端节点的阻值。
——————————
@chasechoose 不知道你所说的USB转CAN是什么工具？这个问题有点笼统，我不知道该如何说明，如果能描述得详细一点就好了。
每个工具的情况可能有所不同。以我以前开发过的一款WIFI - CAN精品真与测试工具来举例，设备本身是可以获取到报文发送结果的。我们打开了CAN控制器的自发自收功能，然后做了一个回读超时机制。（当然这个问题其实很复杂，还需要确认收到的报文确实是自身发送的而不是其它节点所发送的相同CAN ID的报文，这里不作展开）。当检测到回读超时，就可以判定发送失败了。
因此，如果工具在做二次开发的接口时考虑到了检测发送结果的需求，是可以增加一个发送状态查询接口的。
如果设备本身不提供此类接口，你也可以自己做一个回读判断，来确定发送是否成功。
如果你的疑问是CAN总线怎么保证通信可靠性，那么就发送结果判断这一点而言，所有CAN控制器都提供发送slot状态查询寄存器，CAN驱动可以利用这一特性来实现相应的检测功能。
但是在实际使用中，对于应用报文是可以不做此类查询和通知功能的。
在应用层，这个问题可以由接收端的超时监控来覆盖，当超过一段时间无法收到对应的报文时，接收端会记录报文超时故障乃至节点丢失故障，进而执行异常处理。
在应用层以下，从较底层的CAN总线Error Detection、Error Signalling和Fault Confinement机制到较上层的网络管理机制都能可能会覆盖到这个问题。
总体来说，CAN总线功能的实现较复杂，检测机制的冗余性较多，是一个可靠性足够满足大多数车辆信号交互需求的总线。
/*
Revisions:
20161007, 初次提交；
20161011, 增加对第一句话的解释；
20161012, 调整解释的位置，叙述调整；
20161031, 增加回复回复的回复。
*/
我看了下所有的回答，看来国内熟悉CAN总线协议栈研发的工程师比较少。这可能和国内几乎没有Vector、EB、Mentor Graphics这样的第三方供应商有关，产业链上其实缺少了一小环Tier 2。
王博士 @Wang Yu说的内容没什么问题，但看起来有点学院派，所以我想以从业者的视角做一些补充。
已经有主机厂同行大致介绍了主机厂网络组平时与CAN总线相关的工作，因此这里仅介绍OEM以下的内容：
事实上王博士提到的“底层”，在汽车行业的Tier 1供应商中，是非常重要的一块儿，大多知名零部件供应商都会有专门的团队负责这部分模块的研发，比如Bosch为此收购了ETAS的团队（也因此ETAS现在虽然仍然在出售OS，但其中的核心代码是不出售的）。这个“底层”在Tier 1中一般会称做平台，如Visteon正在服役中的有Newton 2.0、Kepler 1.0等平台。同时也会有另一个团队进行下一代平台的研发，和IT圈的产品迭代其实挺像的。
补充一下，王博士的观点也没有错，对于应用工程师来说，底层本身是不需要投入过多关注的，就好像程序员一般不需要了解编译器开发团队的工作。（当然这个类比不够准确，与现在行业的状态其实不太匹配。）
而CAN协议栈，就属于上述（软件）平台中的一部分。CAN总线从驱动层往上，有一系列的软件模块，如果想了解最新的分层设计，可以参考AutoSAR中通信部分的文档。而王博士回答中所提到的工作只包含了驱动开发的前期内容，也就是使CAN总线“通”起来，但这个工作在CAN总线的软件开发中其实只是基础的准备工作，一个懂单片机的应届生可能也只需要一两周，就能实现一个能通信的CAN驱动，然而这个驱动在正式产品中是无法使用的。
在实际的商业化产品中，CAN驱动层也会包含一些复杂的策略，如各种异常的处理，以及性能优化。模块本身还会有可配置性和可移植性的要求，毕竟CAN驱动也是软件平台的一部分，可复用性是一个很重要的考量。
而从架构角度来说，在传统的OSEK/VDX架构下，CAN驱动以上就有交互层、传输层（或叫网络层）、诊断协议层、网络管理、标定、信号/报文/协议网关等上层基础软件模块，几乎每一个都有相应的国际标准来对应，是一个相当专业且门槛不低的行业子领域。也因此，除了知名的Tier 1公司会自己招募一个团队做软件平台以外，一些中小型公司往往会选择购买市场上的第三方基础软件，以降低研发成本。目前国际上知名的第三方供应商有上述提到过的Vector、EB、Mentor Graphics、ETAS、KPIT等，国内现在也有普华、恒润等公司在做此类业务。
对于车载ECU来说，Tier 1的研发大致可以分为系统、硬件/电子、软件、机械/结构几个条线。CAN总线涉及最多的是上文提到的软件条线。系统部分基本只需要与OEM的网络工程师及DRE做一个对接，定期沟通下信号需求、通信矩阵释放、样件提交、测试结果反馈等，真正涉及到技术的工作比较少。硬件部分基本都有现成的方案，主机厂的CAN节点企业标准中往往也会提供参考电路和元器件型号推荐，对于有经验的硬件工程师，通常不会出现设计电路有太多的物理层问题需要修改的情况，偶尔可能会有一些电压、斜率之类的小问题。结构条线一般不怎么会有专门与CAN总线相关的工作。
以上内容展开则太过繁杂，不是一篇回答能够全部涵盖的，因此仅作大致介绍，希望能够有所帮助。
——————————
这里得解释一下：第一句话是我之前随手写这个答案的时候，表达了工作到现在一直以来的一个感受。可能会让很多汽车工程师觉得被冒犯，这里先表示道歉。其实我没有冒犯的意思，之前写的太随意了，表达不够清楚。相信看到我这个答案的同仁们，很多都称得上熟悉CAN总线，只是之前我想表达的，是其中一个特定方面的熟悉。
其实我的意思是，我觉得国内汽车电子行业内，对CAN总线相关协议有深刻理解及开发经验的工程师的数量，相对于整体的研发规模，有点少了。
比如说，国内数万汽车电子软件工程师，用过CAN总线的十之六七，但知道CAN相关各个模块设计原理的，恐怕百不足一。
比如说，国内主机厂的网络工程师同仁们，对CAN总线相关的标准如数家珍，日常工作就是指导供应商们实现相关协议，对提交的软件进行测试与反馈。但又有多少人，去研究过这些标准背后的know how呢？拿网络管理举例，每家主机厂都会有自己的一份网络管理企业标准，描述了一个详细的实现机制。但是，网络管理的协议并不少，有国际标准如AutoSAR CanNm，OSEK Direct NM，有第三方供应商设计的机制如Vector NmBasic，有主机厂设计完善的完全可以当作一份标准的机制如GM GMLAN NM，Volvo Volcano NM，也有主机厂设计的只有较为简单的状态机如Nissan/Renault NDS中所定义的，甚至还有隔壁商用车所采用的J1939 NM，等等。这么多简单的，复杂的，主从的，多主的，其优缺点是什么？选择的依据是什么？不知道在日常工作以外，会有多少人会去进行调研和分析呢？恐怕绝大多数人，像我一样，只能说出一些泛泛的道理，而缺乏有力的实验和数据支撑，以及深刻的洞悉。
需要特别说明的是，由于术业有专攻，我所在的工程师岗位相对会更关注协议的原理和实现，但这并没有什么高下之分，只是行业内的分工不同。
说到know how，这里还想夹带一些私货，不喜欢的朋友可以跳过。
记得有次我去国内某自主品牌主机厂搬砖，看到实验室中几位工程师在用测力计测试一款进口车型的车门铰链的阻尼大小（这方面不太懂，不知道专业的说法是什么）。当时我就脑洞大开了一下。
众所周知，我们国家的工业技术从起步开始，到现在为止，逆向工程从未停歇。这很正常也很必要，是我们快速追赶发达国家的重要方法。但有时候我在想，其实我们的积累已经不少，是不是该多做一些正向的研发了呢？逆向工程虽然能让我们得到一个接近完美的策略或数据，但通过逆向，我们永远只能知道what和how，而无法知道why。拿CAN总线举例，很多软件工程师都知道一般当错误计数器累加到96的时候，CAN控制器就会报一个Warning，但有多少人知道这个数字为什么是96呢？
回到车门铰链阻尼的选择，我是外行，假如让我来考虑正向开发，那我可能会想到，这个实验需要做出所有合理阻尼范围铰链，然后招募不同年龄段、不同性别、不同人种、不同体型、甚至不同职业的人前来测试，并记录下他们的感受，形成一个数据详实的调查报告，再加上各种危险工况的考量，来确定一个合适的数值。当然这个想法过于复杂了，可能国外都没有这么理想化，但我想说，只有通过类似的正向研发，我们才能不陷入“宝马用20N，那我们就用20N吧肯定不会错”的研发惰性中（数字仅为举例）。
有些技术标准，国外一更新，国内就懵了，只能紧跟步伐，根本不明白国外为什么这么变更。非常希望这样的情况，能够通过我们的努力越来越少。
逆向只能追赶，只有正向，才有可能超越。
愿与怀有技术情结的工程师同仁们共勉。
——————————
@只是学电的 关于CAN总线映射到OSI的分层我不是特别了解，因为没有看过ISO/IEC 7498-1等标准。这里提供一些我个人的看法。
前两天正好看到了一个问题个人计算机里面包含网络7层协议的所有协议吗，每一层分别对应哪个部分？ - 计算机技术，其中@invalid s的回答讲得特别好。对于实际开发工作来说，了解七层模型几乎没有实质上的意义，而且我个人觉得即使是用于教学，以七层模型来做讲解也是很糟糕的做法，因为框架性的内容对于概念都还没建立起来的学生是非常苍白的，对产生感性认识毫无帮助。我比较倾向于在培训时从底层（物理层）开始讲起，多举一些例子，这样即使毫无基础也不至于听完一头雾水。OSI七层模型的学术价值可能更于高实用价值。
回到CAN总线，其实这个问题ISO是已经提供了参考的，在ISO 14229-1: 2013的Introduction中，有一个表格Table 1 — Example of diagnostic/programming specifications applicable to the OSI layers（其实一系列的标准里都有提到，且内容还不太一样）：
Application (layer 7) - ISO 14229-1, ISO 14229-3, further standards
Presentation (layer 6) - vehicle manufacturer specific
Session (layer 5) - ISO 14229-2
Transport (layer 4) & Network (layer 3) - ISO 15765-2
Data link (layer 2) & Physical (layer 1) - ISO 11898-1, ISO 11898-2
从ISO提供的信息可以看到，在具有诊断功能时，CAN总线对OSI七层模型基本都有映射。而单独考虑通信功能时，在ISO 11898-1: 2003章节7.1 Reference to OSI model中提到，CAN总线只对应了DLL与PY层。
我个人的理解：OSI七层模型中只有物理层、数据链路层是硬件来实现的（CAN总线线束、CAN控制器、CAN收发器及相关元器件），而其余的五层均为软件实现。
——————————
@Keith 很抱歉前段时间比较忙，回复晚了。
我是软件工程师，不了解硬件原理，因此只能告诉你我所知道的，而且不能保证完全正确。。
这问题还挺复杂的，我尝试做一下分解。
首先，ISO 11898-2: 2003中给出了CAN总线物理连接方式的建议图：
图是我自己画的，原图请参考标准。
可以看到，在预想的状态下，终端电阻与CAN节点（包含CAN硬件的控制器）是分离的，终端电阻处于线束两端的位置（这和终端电阻的原理有关，我不懂本质这里就不妄加说明了），标准也特意强调了这一点。
终端电阻的阻值是一个经验值，标准在7.5.2 Termination resistor章节给出了标称值120欧、最小值100欧和最大值130欧，同时也说明了，根据不同的拓扑、比特率和电压转换速率，偏离标称值是可能的，并且，在每个项目中测试一下其它阻值的适用性也是必要的。
而现在主机厂在设计CAN线束时，一般并不会把终端电阻做在线束上（这也需要主机厂的同仁来解释具体原因，推测和下文提到的电气特性或架构设计有关）。目前一般将终端电阻设计在电控单元的PCB上，参考电路如下：
这样分裂终端电阻设计的好处是可以通过一个参考电平稳定电压，降低共模干扰。
主机厂通常会在CAN节点企业标准中推荐这样的参考电路，一条总线上CAN节点的个数一般大于两个，而CAN总线又只需要两个终端电阻，因此就引入了终端节点和非终端节点的概念。
终端节点一般设计在线束的最远端，近似标准中CAN总线的物理连接方式，其它节点则设计为非终端节点。由此可知，终端节点上的终端电阻应为120欧，若为分裂式设计，则应为两个60欧电阻。而非终端节点通常使用一个较大的阻值（具体原理不了解，不知道是要模拟开路还是其它原因，但由于电阻是并联的，至少要保证加上非终端电阻后，总线间的等效阻值与不加之前相比近似相等），如1.3千欧 * 2。
因为我不怎么关心元器件BOM，目前唯一有印象的就是有项目采用过60欧 * 2和1.3千欧 * 2的典型值（500kbps的波特率）。至于9千多欧我没有见过，如果确实无误，那应该是主机厂出于电气特性需要所计算出的非终端节点的阻值。
——————————
@chasechoose 不知道你所说的USB转CAN是什么工具？这个问题有点笼统，我不知道该如何说明，如果能描述得详细一点就好了。
每个工具的情况可能有所不同。以我以前开发过的一款WIFI - CAN精品真与测试工具来举例，设备本身是可以获取到报文发送结果的。我们打开了CAN控制器的自发自收功能，然后做了一个回读超时机制。（当然这个问题其实很复杂，还需要确认收到的报文确实是自身发送的而不是其它节点所发送的相同CAN ID的报文，这里不作展开）。当检测到回读超时，就可以判定发送失败了。
因此，如果工具在做二次开发的接口时考虑到了检测发送结果的需求，是可以增加一个发送状态查询接口的。
如果设备本身不提供此类接口，你也可以自己做一个回读判断，来确定发送是否成功。
如果你的疑问是CAN总线怎么保证通信可靠性，那么就发送结果判断这一点而言，所有CAN控制器都提供发送slot状态查询寄存器，CAN驱动可以利用这一特性来实现相应的检测功能。
但是在实际使用中，对于应用报文是可以不做此类查询和通知功能的。
在应用层，这个问题可以由接收端的超时监控来覆盖，当超过一段时间无法收到对应的报文时，接收端会记录报文超时故障乃至节点丢失故障，进而执行异常处理。
在应用层以下，从较底层的CAN总线Error Detection、Error Signalling和Fault Confinement机制到较上层的网络管理机制都能可能会覆盖到这个问题。
总体来说，CAN总线功能的实现较复杂，检测机制的冗余性较多，是一个可靠性足够满足大多数车辆信号交互需求的总线。
责任编辑：
