汽车总线设计和测试经典问答总汇(中)

13、CAN总线如何和ECU可靠的连接？CAN协议是不是必须得用SEA1939，这个协议好像是商用的吧？

答：CAN只有物理层和数据链路层，在具体应用中还应当根据实际情况按ISO的7层协议的要求制定其它层．J1939只是建立在CAN之上的应用层协议，类似的还有GMLAN，CANOPEN等。J1939叫商用车应用协议．因为车通常分为商用车和乘用车，J1939是为商用车用的，而不是“商用的”。

14、现在can在轿车中很普遍了。对于can总线的应用层，各个汽车公司像大众通用等汽车公司是不是都有自己的协议？如果想自己设计应用层的协议(如果可能的话)，应该考虑哪些方面呢？j1939协议前景如何呢?

答1：从技术的角度来看，应该自己设计应用层协议，实际也是整车厂的知识产权。这也是为什么大众、通用都有自己的协议但是还不对外公开的原因。设计中要考虑的主要问题举个例子来说：

比如ABS提供车速信号、自动变速箱需要车速信号。在设计应用协议的时候就必须考虑使用合适的消息传送车速信号，主要考虑的因素就是ID应该是多少、周期是多少。影响ID分配的主要就是延时(或时延)问题。但是目前的设计技术很难保证这一点，建议参考国外目前研究比较热的设计技术，那就是基于控制消息延时的设计技术。其核心思想就是考虑从信号产生、总线传输到信号用于控制全过程的时间要求。也就是对从ABS产生车速信号，通过总线发送，到自动变速箱使用车速信号进行控制的全过程的时间提出时间要求。ID、周期的设计都必须满足这个时间要求。考虑整车网络，考虑每个这样的相互关系，最终对整车网络的应用层协议进行设计，并可以进行整车的网络优化。

Mentor Graphics 的VNA是采用该技术实现应用层协议设计的自动化工具，它根据用户提出的时间要求，可以自动实现整车网络规划和应用层协议设计。了解这个工具的技术点，可能有助于理解，另请参考以下方面的文献：实时任务调度算法、CAN消息延迟时间计算、CAN调度等等。

J1939协议是由SAE(美国汽车工程师协会)——卡车和公共汽车电气电子委员会下的卡车和公共汽车控制和通讯网络分委员会制定的高层CAN网络通讯协议。它主要用于为重型道路车辆上电子部件间的通讯提供标准的体系结构。

其应用的主要对象是大型载货卡车、客车。在这方面的应用比较成熟，国内这方面还是空白。因此在卡车、客车上的应用是非常有潜力的。

但是如果把它照搬到轿车上，我个人还是持保留意见的。

答2：J1939的应用在国内早就开始了，如：一汽的AMT，还有北京路上跑的不少公交车都有国内自已研发的零部件与国外零部件共处于一个J1939的网络中，所以J1939在国内应用可不是空白．

答3：Bosch最早开发CAN的标准和协议，Bosch做了最早的硬件、软件和测试，不过现在的软件也不全都是Bosch开发的了，也有很大一部分是瑞典Volcano（现属于Mentor Graphics）为Bosch开发的，其中包括很多测试软件、代码生成工具等等。

VW有用于Powertrain/Driveline的High Speed CAN和用于Infotainment的Low Speed CAN两种基本的总线、网络传输协议TP2.0，当然另外还有基于CAN的EOBD诊断总线，以及各种网关。目前CAN的协议是和软件供应商Vector、IAV以及几个主要ECU供应商Bosch、Siemens VDO等一同开发的。

GM、Ford、DCX的CAN来源比欧洲要复杂，GMLAN Single Wire CAN (J2411)是源于Class II的，其中很多思想比如Power Mode和Class II是相同的，而HSCAN就是基于J2284的。GMLAN、Ford NOS和DC CAN现在还没有完全开发完整，主要的应用也是和Vector和其它供应商一同开发的。

答4：我始终认为CAN网络是一个无中心的分布式网络。CAN协议处理器只负责数据的传送而不参与具体操作。真正操作的是发动机，刹车系统，照明系统等等，所以除了自身的网络管理外根本不存在什么CAN网络的应用程序。

关于控制协议的问题,我认为实际上是各个部件的接口决定的。只不过由于国际大厂家自己拥有设计制造发动机，变速箱等关键部件的能力，希望部件配套厂家改变接口以适应他们的系统(当然也得花钱)来达到协调统一。也没什么神秘的，对于无法提供关键部件的整车厂商，还得使用部件厂商(如博世，TRW等)的接口。总而言之，整车厂的控制协议不同的根本原因是由于使用不同部件造成的。

当然我们不能否定国际大厂垄断的企图。但是我们应当理解协议差异性的根本所在。从而明白，只要各部件都公开各自的控制协议接口，就完全可以协调统一。

答5：目前世界各大汽车公司都有自己的协议，这些协议可以根据不同的车系和功能配置进行裁减，适用于不同的平台。不同厂家的协议彼此互不兼容。如果要自己制订功能完善、适应能力很强的协议，对协议制订者有很高的技术要求。协议开发小组必须对协议应用的领域非常熟悉（如车身控制系统，动力总成系统），只有这样才能准确定义协议中的信号、报文以及对它们的具体要求。协议制订者必须熟悉现场总线通讯技术（CAN、LIN)。这些技术包含传输协议、网络管理、故障诊断等方面的内容。协议制订者需要全面掌握与协议相关的多方面的技术内容。J1939协议是美国汽车工程协会开发的汽车网络协议，主要用于卡车、巴士和工程车辆，轿车不使用该协议。

答6：各个汽车公司的确针对自己的各个系统拥有不同的CAN应用协议。

我们自己的汽车公司想制定自己的应用层协议，需要考虑的问题我觉得应该包括：

1、功能的满足：报文内容是否覆盖了所有节点的信息获取需求；

2、性能的满足：报文的周期、ID的选择是否能够满足节点在规定的时间获取到需要的报文；

3、容错能力：对于例如动力总线等要求数据正确性高的总线系统，需要考虑是否在报文中正加校验数据，如果报文出错状况下是否应该有备用方案等容错的措施；

4、传输协议的考虑：包括是否需要多包报文发送、是否需要握手信号和应答信号等

5、故障诊断协议：如何实现故障诊断（该方面的具体实现会覆盖了1、2、4方面的内容）

J1939目前在重型车辆上使用还是比较广泛的，国内外有许多使用J1939作为重型卡车CAN网络的案例。由于它的规范制定比较完整，用户使用起来也比较方便。

15、请问，基于消息的延时如何做到多Master间的同步，有无使用时间戳。

答：消息的延时主要受应用层影响，CAN就是多Master系统(你是否另有所指？)，你这里的同步具体指什么呢，物理层的同步还是应用层级握手，或者是......

16、从所发表的期刊论文上来看，CAN在国内的应用好像是在工业控制上，而且也很少提及上层协议。现在汽车工业热起来了，CAN的应用又回归到汽车上面。只知道1939是为卡车写的协议，那其它的车辆，如小型客车，上应用的协议一般是哪些，像欧洲的DeviceNet、CANOpen、CANKingdom等是不是都是为汽车的应用写的，我国是不是有这方面的应用实例了？

答1：1939是所有的协议基础。小型客车上应用的协议没有太大的区别同卡车的协议。各个公司有所不同。

答2：CANKingdom被认为是基于CAN的高层协议的原型，但是它不是一种基于OSI 参考模型的应用层。CANKingdom起源于北欧瑞士，由Kvaser建议将CAN应用到纺织机械厂，并在该领域建立“CAN 纺织机械用户集团”。1989年，他们研究出通讯原理，1990年早期建立“CAN Kingdom”开发环境。

CANopen是基于将高层应用协议标准化这样一个目标而开发。1992年，由VMEbus杂志主管发起，将用户和厂商集中在一起讨论应用协议标准化问题，试图建立促进CAN技术发展的中立平台。同年5月成立CiA“CAN in Automation”组织。该组织在Philips医疗系统的CAN应用经验的基础之上，设计了CAL——“CAN应用层”。但是应用CAL协议需要用户建立自己的子协议，所以没有实现真正意义上的标准化。从93年起，在Esprit project ASPIC范围内，由Bosch领导的欧洲协会研究出一个原型，由此发展成为CANopen。它是一个基于CAL 的子协议，用于产品部件的内部网络控制。在项目完成之后，CANopen规范移交给CiA组织，由其进行维护和发展。在1995年，CiA发表了完整版的CANopen 通讯子协议。CANopen 不仅定义了应用层和通讯子协议，也为可编程系统、不同器件、接口、应用子协议定义了页状态。主要应用与工业机械自动化，如航海、医疗系统等

DeviceNet和 CANopen是两个定位于不同市场的标准应用层协议。它的产生非常有意思，来源于AllenBradley、Honeywell合资项目的终止。因此AllenBradley研究出了DeviceNet，Honeywell研制出了SDS。DeviceNet面向工厂自动化控制。

此外J1939也是应用层协议标准化发展过程的产物,源于农业交通工具总线系统LBS被制定出。

17、一个新手接触CAN不久，请教CAN测试重要还是协议制定重要？论坛上有的人说测试重要，国内的讨论也是铺天盖地。又有人说协议制定重要。

答1：测试和设计的重要性，在不同设计思路中有不同的体现目前应用层协议制定的方法可以分为两大类，一类是测试为重心的方法，一类是设计为重心的方法。

第一种方法也称为投票法或试验法。这是一种工程设计方法，各个供应商对协议提出要求，整车厂集成要求，通过测试验证协议可行性，随后发布协议。测试的功能除了验证协议的实现外，还有一个重要的任务就是对协议设计进行测试，试图解决ID分配不合理、消息冲突问题等等。这种方法的重心就是测试，因此测试比较重要。

第二种方法是系统级设计法。这是一种理论设计方法，它提出了完全不同的需求，供应商只需要提供相应的参数，根据一定的理论模型对网络通讯特性进行计算，如信号延迟、总线负载等。以此为基础，考虑设计需求，通过一定的调度算法，对每条消息的ID进行分配。方法的核心就是优化这些特性参数，保证整车网络通讯的实时性能。因此在这种设计方法中，设计是重点。从V型图来看，第一种方法重点在V型图的右边，第二种方法覆盖的是V型图的左边。

测试就是验证？验证表示的是我们有一个标准，测试被测对象是否符合。但是目前汽车电子的测试不能一概的称为验证，因为它还要测试协议设计是否正确，协议设计中是否有瑕疵。验证的输入是被测对象的特性，参照的是标准，输出的是两者是否符合。

而我们现在的测试，输入的既有被测对象的特性，又有所谓的标准，输出的是协议是否需要修改、系统是否可行、设计是否符合需要。注意这里引出了一个难以让人理解的地方，我们要测试ECU是否符合标准，但是我们却又在根据测试结果在怀疑这个标准。因此除非你有非常雄厚的技术和经验积累，否则你始终在这两者之间徘徊，浪费时间和金钱。中国目前就处于这种状态，但是我们却要依靠测试来推动技术的发展，难以想象。

我们需要的是一条新的发展思路，而不是沿着老外的旧路重新来过。

如果依靠测试就能提高我们的设计水平的话，我们真应该回顾中国这几年都做了些什么？我照着国外的数据库，每天都在测试，每天都在修改协议。。。因此事实是我们在基于测试做设计，而不是国内对于设计普遍比较重视。

没有设计怎么说的上测试呢？相反设计才决定了测试的体系。举个例子，整车网络的电气特性参数，比如ECU的终端电阻、电容，这些参数都是与特定的网络环境有关系的。可能因为线束走线不同就有所不同。设计人员知道影响这些参数的原因和可能出现的问题，而这些都可以成为建立测试方法的输入。

测试是比较重要，但是一定要比较的话，我倾向于选择设计更重要。其实电子行业的发展可以成为参考，请大家考虑为什么EDA工具在电子设计中处于如此重要的地位？而且现在国际上的趋势是基于系统级的设计、建模等等。重点是系统级！如果我们还在强调测试的话，走的是国外过去发展的道路，是背离系统级的设计思路，根本就没有考虑国际发展的趋势。

答2：我觉得这两样很难放在一起比较。离开了特点的协议，工程师只能说是有了CAN的概念和一堆标准，并没有一个实实在在的CAN总线系统。一个CAN总线的存在很大意义上取决于通讯协议的建立。无可非议的，协议制定的质量将会直接决定CAN总线系统的性能。

对于一个CAN系统来说，很多的工作量是后期的测试工作。只有通过后期的大量的测试，才能保证这个系统并不是一个实验室里的‘雏形’，而是具有一定实际意义的，可以面向实际应用的系统。事实上也只有通过测试，才能最终验证协议制定的好坏。

所以，从我的观点出发，协议制定和测试应该是属于CAN总线系统中的一头一尾两个关键，其重要性都不容质疑，也不能进行比较。

答3：协议和测试是V模型开发流程中的两个独立部分，两者的参考依据都是系统需求。协议是保证如何满足系统需求的基本标准与原则；测试则是检验这些标准与原则是否符合实际的需求。两者相辅相成，没有标准/协议就没有系统设计的依据，测试也就无从谈起；没有测试，就无法验证标准的正确及合理性，这样的协议也就没有实际意义。标准与测试都是基于大量实践经验的，不可能假设借助某种标准化的工具自动生成。标准化的工具只能在缺乏设计经验以及系统设计的初期，为标准的制定提供一个辅助作用。目前，国内的设计水平不能与国际上达到同等高度，主要就是缺乏测试（因为国内对于设计普遍比较重视）。

18、解析CAN协议应用层与应用程序

答：应用层和应用程序是不一样的。应用层是指通讯功能的应用层。它并不定义和描述应用程序参数，它提供的只是通讯功能与应用程序的通讯接口。包括：定义通讯服务、传送过程数据、诊断信息及标定信息。设备监控和网络管理也一般定义为应用层的一部分，有的也将传输层的部分内容纳入应用层实现，比如超过8个字节的数据传输。应用程序就完全是指控制算法等应用代码。它定义控制算法相关的数据和参数。

在目前ECU开发中，应用程序代码包含了应用层代码。其缺点在于以下三个方面：

1 应用程序发生变化，必须考查应用层是否还能满足要求

2 通讯协议发生变化，整个应用程序及应用层代码都必须重新编译测试。这个问题是造成整车厂在协议开发中不能起主导作用的主要原因之一。所以有很多国内的整车厂的朋友告诉我，他们有新协议了，希望某些国外大型供应商实施新协议时会遇到极大的阻碍。一是不愿意做，二是要做就得花大笔重新开发的费用(只是重新编译和测试，但是人家就是要收高额开发费)。

3 严重阻碍了节点和设计的重用。由于应用程序和应用层融合在一起，难以实现即插即用的效果。

解决方案就是接口标准化，即将应用层从应用程序中分割出路并标准化接口。 AUTOSAR的一个特性就是标准化接口，实现即插即用。Mentor Graphics的VTP也是一个典型的例子。

19、ID分配的影响因素有哪些？

答1：我觉得，ID的分配首先当然是要考虑优先级的问题，按照具体应用的系统中的实际情况，针对不同的控制实时性要求来分配ID。

其次，就是可以考虑将在系统中同类的控制类信息或者状态信息，采用类此或相关的ID开头引导，这样在通讯应用层的处理和屏蔽上也会比较方便。

最后是，参考现有的总线系统中的ID定义。毕竟CAN总线系统是讲究兼容性和可扩展性的，除非是全部重新来过，否则必然会有需要和现有网络匹配的问题。参考现有的，成熟的系统中的ID定义是很实际也很高效的做法。只是很多无关人等很少有机会接触到类此VW或GM的现有协议…

答2：CAN的相关标准中，除了J1939以外，别的基本上没有对ID有具体的规定。只不过现在大多数总线系统多多少少有借鉴国外......

兼容性也不仅仅是体现在ID定义上面，就算是ID全兼容，数据场长度不同的话，兼容性也是有问题的。

20、请教对于can总线的应用层，各个汽车公司像大众，通用，奇瑞等汽车公司是不是都有自己的应用层协议？他们自己设计的应用层的协议是不是各不一样？他们自己设计的can总线是不是以j1939为基础？

答：整车厂都有自己的应用层协议。上面的几个公司是轿车厂，其CAN协议应用层不是以J1939为基础的。

21、目前正在开发的基于SAE J1939的CAN空调控制系统，目前面临的问题是：目前自己设计的应用于空调系统的4个CAN模块相互通讯，控制良好，但是和整车的其它CAN模块的通讯和协调不能实现。请问是否是应用层的软件的问题，以及是否可以采用VNA软件对我公司的整个软件设计，应用层的协议进行调试可以最终解决我们的问题？VNA软件的大致成本如何？

答1：在基于J1939的网络中，通常一个网络不要超过9至10个节点，您一个空调系统就用了4个节点，可能和其它节点就难匹配了。对于CAN总线来说，同一网络中，节点越多，冲突越严重。

答2：关于CAN通信比较复杂。首先，物理层的电器参数可能影响通信；其次，CAN控制器设置（采样时间、同步等）也影响CAN通信；另外，数据链路层以及网络管理都可能影响CAN通信。在工作环境不是很恶劣的情况下，终端电阻作用与网络的规模以及总线长度有关，一般不会造成网络通信阻塞。可以通过以下方法，逐步解决通信出错问题。

1 屏蔽掉本节点的发送功能与硬件过滤功能，检查接收是否正确；如不正确，可能是控制器参数设置不正确、ID长度不一致或者物理参数不兼容。如果能正确接收，而数据不正确，这是由于应用层引起的，需要该系统应用层协议。

2 打开发送功能的广播通信部分，检查是否能成功发送，如果不能发送出去，可以肯定是物理层或控制器部分的问题；如果能够发送出去，问题就可能在应用层。

22、正在做一些CAN总线在客车应用上面的研究。但是对CAN总线如何保证实时性和可靠性方面比较迷茫，不知道有什么比较好的测试方法或工具。在动力总成方面中高速CAN能否保证其实时性和可靠性呢？

答：当前车辆上的动力系统一般都使用高速CAN来传输数据，例如J1939协议规定的速度为250k，一般来说可以保证系统需要的实时性和可靠性。但是我个人觉得，保证实时性和可靠性的前提，在于如何设计好合适的应用层协议。

当然，随着对于安全性等需求的增加，可能未来的动力系统传输的实时性、可靠性将要求越来越高，会超出CAN总线能够提供的能力，所以目前将Flexray作为未来取代CAN的协议。

对于可靠性和实时性的测试，需要对总线性能、功能在整车或者动力系统台架上进行试验。

23、针对不同的网络系统（CAN、LIN、MOST、Flexray）有哪些常用的测试工具和测试手段？

答：CAN网络测试工具可以使用Vector公司提供的CANoe/CANscope/CANstress系列工具。CANoe提供了Test Feature Set，包括了CAN、LIN和MOST网络测试所需要的函数，能够较为方便的完成网络测试案例制定、执行以及报告生成。CANscope以及CANstess工具能够完成CAN网络测试中所需的电平级别示波器和干扰仪的作用。

CANoe的Test Feature Set也提供了LIN和MOST的网络测试函数，可以进行这两种网络的测试。另外Vector还提供了具有干扰仪功能的LIN线缆，通过CANoe控制该功能，实现LIN网络测试所需的干扰环境。

目前针对FlexRay，CANoe的FlexRay选项可以做相应的网络测试，但是针对FlexRay网络的专用测试工具目前还较少。随着FlexRay被确认为下一代车载网络，相应的测试工具应该也会被开发出来。

24、汽车行驶记录仪就像飞机的黑匣子一样，国家也出了一个标准，请问中国现在有成熟的产品吗？

答：汽车行驶记录仪一般分为2种类型。一种是早期的传统类型。那时汽车网络还未普及，行驶记录仪直接与传感器或数字IO相连，记录模拟/数字信号。这种行驶记录仪线束连接复杂，通用性差，因为不同车型的传感器配置、类型，提供的数字信号不同。另一种行驶记录与是连接到网络系统的行驶记录仪。现代的行驶记录仪多数是基于网络系统的。由于汽车网络实现了数据共享，所有在网络系统中传输的信号都可以记录。因此连接到网络的行驶记录仪线束少，硬件结构简单，记录参数多、功能强大。但是开发连接到网络的行驶记录仪需要掌握针对某种车型的网络系统通讯协议（如J1939等），软件开发是核心。目前国内开发的行驶记录仪大多数属于第一种类型。

答：MC9S12DG128有两个独立的MSCAN控制器，与pca82c250硬件连接无错误就可以构成双路CAN了。不过建议你使用飞思卡尔的驱动芯片，匹配会更协调一些。这双路CAN你可以把它用做不同速率的网关，也可以做数据传输。应用协议是要根据具体情况来确定的，当然，你也可以不去理会任何的标准，按自己的意思去组织。