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

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

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等），软件开发是核心。目前国内开发的行驶记录仪大多数属于第一种类型。

25、泰克和安捷伦的汽车电子方案如何？

答：泰克主要生产示波器，而安捷伦主要是频谱分析仪。解决时域问题，要用示波器(测量灵敏度为mV级)，解决频域问题，要用频谱分析仪(灵敏度为uV甚至nV级)。时域设备，一般用来解决电路功能问题，而频域设备，一般原来测量微弱信号(=例如噪声问题，即EMI问题)。

容向的产品，是解决频域问题的，需要和安捷伦等公司的频谱分析仪配套使用。安捷伦的频谱分析仪不能测量电磁场的空间分布，容向公司的EMSCAN利用安捷伦的频谱测量功能，采用阵列探头，能测量电磁场的空间分布。安捷伦的汽车电子解决方案分为几种：生产线自动测试系统；频域测试(第三方公司利用安捷伦的产品搭建的测试方案)；示波器测试方案，分为两类产品，支持windows XP的54800系列产品有一个选件，支持CAN/I2C/SPI的解码分析功能，在显示波形的同时显示解码结果，并支持类似逻辑分析仪的列表显示功能，协议搜索功能，同步触发功能，不过这些都是新方案，大多用户尚不了解。安捷伦示波器只能显示CAN信号的波形，横河示波器不仅能显示CAN的波形，而且还能分析CAN信号的各种特征。

双方都有CAN触发功能，区别横河带CAN分析功能，对于物理层信号分析特别有效。

26、请问如何写一个简单的CAN应用层通讯协议代码。应该从哪几个方面来构造协议？还有实现通讯协议的程序代码结构是什么样的？

答1：CAN协议的基本要素是ID、周期和信号与消息的映像关系。因此构造协议的主要任务是ID分配、定义消息周期、确定信号与消息的映像关系。这三个方面的设计都同等重要，设计要考虑的主要因素有数据传输的实时性要求(即所谓的时序)、数据的相对重要程度、与数据相关的应用控制算法对数据的时间要求。

协议设计实质上是非常复杂的工作，对于国内来说，由于我们缺乏相应的经验，国外又对我们进行技术封锁，因此到目前为止这还是阻碍中国技术发展的主要障碍。

国际上也存在一些现有的标准，如CANopen、SAE J1939.SAE J1939这是一个有汽车工程师协议牵头制定的应用与卡车电控网络的协议。不过它主要是应用与卡车的电控系统，不能直接照搬到轿车控制系统中。

但是随着汽车电子的发展，汽车电子设计分工也越来越细，这部分工作也有厂商提供工具实现协议的计算机辅助设计。比如Mentor Graphics公司的VNA就是是一款自动化的协议设计软件，了解它的设计技术有助于你理解协议构造的方方面面。详细信息欢迎进一步交流咨询。

首先CAN通讯功能包括物理层、数据链路层和应用层。物理层、数据链路层已经由硬件实现，目前都已经标准化，有现成的部件(CAN控制器和收发器)选择。因此在单片机上加上CAN控制器、收发器，软件实现相应的驱动程序就基本实现了CAN的通讯功能。

但是这对于汽车电子上的应用还是远远不够的，因为数据链路层有很多功能没有定义如具有逻辑关系的消息之间的功能实现、网络管理等等。

因此通讯协议的程序代码的结构应该是底层驱动+应用代码（通讯功能的应用代码）。

如果考虑目前汽车电子嵌入式软件的技术发展，未来的结构应该是底层驱动+应用代码+抽象层。汽车电子软件开放式体系标准AUTOSAR也基本是这样的思路。目前也有很多软件厂商提供现成的解决方案，ECU软件开发只需要在该解决方案提供的基于数据读写的接口之上实现控制算法。这样做的好处在于软件设计人员可以把专长用于集中设计控制算法、保证其可靠性。这样的产品如Mentor Graphics的嵌入式软件（VTP + 网络管理 + 诊断）就是这样的应用例子。

答2：通常，包含了CAN控制器的控制器的供应商，诸如：FREESCALE或者MICROCHIP还有INFINEON，本身都会提供很多基于自身产品的CAN通讯的底层代码。通过这些源代码，基本的CAN通讯的收发等功能都可以实现。

而至于CAN协议的制定，我觉得，是应该从系统需求出发，针对目标系统的具体需求，和特性来制定出最优的CAN通讯协议。这个是没有一个既定的原则的，虽然说很多现有的在类似应用中的CAN总线系统的协议有类同的地方，但是我想这并不表明对于CAN总线的协议制定存在什么通用的原则（对于相关标准则除外）。

27、VNA自动化的协议设计软件”是不是可以设计协议，减轻编程工作量？所设计的协议是否可以算是特有协议？是否具有兼容性？

答：VNA设计的就是通讯协议，严格来说是CAN协议的应用层...... 但是VNA是自动化协议设计软件，它输出一个可靠和正确的协议，可以节省集成测试的大量工作量，因为不需要再对协议的正确性进行验证了。而且Volcano是一个完整的解决方案，结合其它产品，Volcano能提高整个设计流程的效率、减少成本投入。

28、EMI的问题和信号完整性的问题，是相互关联的，如何在定义标准的过程中，平衡两者?

答：信号完整性和EMC还处于草案中不便于公开，至信号完整性和EMI两者如何平衡，这不是测试规范的事，如果要达到二者平衡，最好是降低通信速度，但大家都不认可。

29、如何看待UWB技术在汽车电子中的应用？应用现状如何，前景如何，将来可能在汽车电子的哪些方面有所应用。

答：UWB和以往的无线技术相比，据有非常宽的带宽(可达GHZ)，通信方式也与通常的无线通信不同，采用的是短脉冲。它本身具有很强的抗干扰性，对其它通信系统影响也小。目前汽车电子厂商及研究机构都很看好他的这些特点，将来很可能首先在汽车防碰撞传感器方面得到应用。

30、请教PCB电路板的两线间距最小距离是多少，UL and CE的标准是多少？

答：正常情况下，PCB电路板上两线的间距应该控制在7mil或者以上，但是实际上这个距离受很多因素影响，高密度PCB上，也有5mil间距的。影响的因素主要是PCB生产厂家的工艺能力(需要咨询PCB生产厂家)，信号线的种类(如果是时钟线等具有较大能量的信号线，应该间距在3×7mil左右)等。UL和CE对PCB板上的布线没有任何要求。

31、对车载电机控制来说实时性要求很高，一般来说要求和控制周期同步观测控制变量，请问有何解决方案！

答：上次介绍的WE7000(基于PC的虚拟仪器)在车载电机评价方面是很好的测试仪器。它通过外部信号输出实现与PLC控制器同步，它还可以对模拟信号波形输出及脉冲信号输出同步测试。

32、众所周知汽车电器组件和模块的工作环境及其恶劣，发动机周边环境温度高大70C， 长期的运行带来震动，潮湿，海边盐雾，以及北方地区的－40、50度低温，烦请概述一下汽车电子组件/模块的可靠性试验的项目，以及其试验环境要求？

答：1 试验环境就是汽车实际使用的环境。比如温度、湿度、振动等条件尽可能模拟实际可能到达的条件，然后进行测试。

2 汽车电子组件/模块的可靠性试验通常用带有振动试验仪的温度试验测试机进行的。

33、LIN收发器在车门窗等控制中应用很多，但其高压和大电流容易引起EMI问题，请问如何降低车身控制模快的EMI？

答1：LIN(汽车本地互连网络)是一种用于汽车中分布电子系统的新型低成本串行通讯系统，针对一些低端应用而设计，采用单线传输。LIN总线典型的应用有车门、导向轮、座位、马达、气候控制、照明、雨水传感器等。

LIN总线的EMI问题，体现在两个方面：

一是LIN总线本身，由于LIN在车内的布线很长，容易产生较大的EMI。LIN内传递的电信号包括本身的有用信号，也可能存在无用信号(干扰)。为了保证产生较低的EMI，不仅要尽可能不让干扰传递到LIN上，还要让LIN上的有用信号产生尽可能少的谐波。减少干扰的方法，必须在电路设计上进行考虑；而减少有用信号谐波的方法，可以采用R/C滤波等方法，让传递的有用信号变平缓。

二是LIN总线命令的执行部分，例如车窗升起的马达电路。这部分的EMI方法，和具体控制部分有很大关系。通用的方法是让驱动输出变尽可能平缓，采用汽车车身进行电磁屏蔽等。

答2：由于LIN信号传输过程可等效为为电流信号的传输，电流信号传输的抗干扰能力很强(其低电平时，LIN总线中的电流超过了10MA)，但它产生的电磁干扰相对而言比较大。降低LIN EMI的大约有三种方法：

1 采用符合LIN2.0标准的LIN收发器；

2 降低通信速率，尽可能缩短LIN的连线。LIN的主页是www.lin-subbus.org这个subbus有两个含义：其一是信息要少，所以通信速率低，目前S40采用的通信速率为10K。其二是通信距离要短，数量多，LIN是CAN的扩展，是它的子网络，因此它在始终在CAN节点的附近，S40车身只有一条CAN，但它有9条LIN，有的LIN只有一个节点．LIN通信距离越短，其EMI就越小。

3 采用外部电容，电感和磁珠降低通信方波信号的斜率，最好不要用电阻，因为电阻要损失信号。实际上1，2和3具有相同的意思，因为通信方波信号的斜率越低，其波形就越圆滑，EMI干扰就越小，而通信速率就越低。

34、请教关于CANOPEN的开发问题？？我现在准备用含有飞思卡尔的MC9S12DG128的开发板上，来编译CANOPEN协议，但是因为我是初学者，我现在先要实现两个CAN口的通讯，由于MC9S12DG128中有两个CAN口，所以我打算用收发器pca82c250，来连接两个CAN口，您看可以么，在此之前，我已经实现了MC9S12DG128中MSCAN的自发自收的功能，而且发的内容在内存观察器可以观看，逻辑也正确，我用的是CodeWarrior编译软件的。如果要加上pca82c250，那么我程序需要改什么呢，除了把LOOP设置零，让它退出自发自收功能 以外。我的最后功能是要在这个芯片上实现CANOPEN的I/O设备的输入输出，那我如何自己去编译协议呢，能给我一点资料或者例子么？

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