汽车总线设计及测试经典问答

scott_club

　　1、作为高校教师，今后也想把汽车总路线作为研究方向，能给一些建议吗？在这样的环境下，构造总线测试平台把哪一方面作为重点研究好一些呢？

　　答：车用总线的测试的范围很宽，大概分为两个方面的，一个方面是功能测试，一个方面的性能测试．功能主要是测试基本的通信功能，如总线上的节点能否正常发送和接收信息．性能主要是指在各种状态（不同的电磁环境，气候环境）的通信的各种性能，如实时性，故障处理能力等．更高层次的功能就是性能，功能和性能之间的划分是没有确定的界线，随着技术的不断进歩，一方面性能方面的要求，不断转换为功能性的要求，同时新的性能又在不断的产生。

　　从总线测试方面来说，它功能和性能的要求和属于汽车电子的非电源线信号传输方式的测试一类，大家可以参考ISO7637-3ISO11452，GMLAN，I2602，I1939等资料。

　　由于学校主要是教学（我个人认为），最简单的方法是购买用于PC机上的CAN/LIN卡（如：LiGaowei他们的产品），然后自制一些节点（对于CAN来说，可以用89C51＋SIA1000构成）就行了。

　　由于测式和设计不仅仅是总线问题，它涉及嵌入式系统的软硬件设计和测试，内容多一言难尽，很多方面还处于探索阶段。

　　2、怎样解读国内的汽车can总线研究现状？是研发、成本或国内的测试方式、手段制约了CAN产品的出现，还是其它的因素？

　　答：CAN，LIN的应用首先要有MCU，而国内生产的汽车零部件中含MCU的少之有少，这好比从奴隶社会社会一下过渡到社会主义社会一样，虽然很难，但会成功。

　　3、目前中国总线的趋势是什么？而且要设计好总线要注意哪些问题？最后市场上的一些汽车生产商做总线有哪些需求（中国）？

　　答：目前，国内在总线方面处于开始研发初始阶段。

　　在某些研究所、或者高校，已经做了一些工作，但是实际涉及到复杂的关键性的网络协议设计（例如汽车动力总线的设计），还不成熟，用于实际产品的非常少。对于所设计的网络缺乏测试策略、测试方法及测试评价。

　　其实国内网络开发方面，与国外的差距在于协议的制定与测试，而引起差距的最重要原因是实践经验。国外的CAN网络设计已经进行了二十年，各公司成熟的网络协议都积累得到的，而国内厂商只是处于开始阶段，谈不上积累。

　　国内厂商要形成自己的自主网络协议，需要加强对车辆等应用背景的理解；参考国外的网络协议；实践和总结。特别是实践，做出来的东西一定要用，要改进，才能摸索总结出自己完善的规范、协议。

　　另外，还需要有超前的意识，不能只是跟踪。去年欧洲已经确定将FlexRay作为替代CAN的总线协议。国内的研究机构也应该从现在开始进行，减小我们与国外技术时间差距。

　　4、到哪里可以获得与汽车故障诊断相关的协议？

　　答：不知道你说的故障诊断是什么意思，在汽车电子领域里说的Diagnostics不止是为了故障诊断。关于协议，如果你的诊断是基于K-Line的，就要遵循ISO-14230，也就是“著名的”KWP2000。如果是基于CAN，物理层遵循ISO-11898，数据链路层、网络层和应用层遵循ISO-15765。另外还有一份ISO-14229，算是对所有诊断功能的一个整体描述。

　　5、请教计算机如何通过汽车故障诊断接口获取汽车实时信号和故障代**？

　　答：汽车故障诊断目前主要是通过K线来实现，基于K线的诊断协议为KWP2000（KeyWordProtocol2000)。KWP2000协议只是一个诊断协议的框架，其中包含了很多必须由具体的制造商自定义的内容（如故障**格式等），这些内容各厂家都不相同。汽车厂家在实现它们自己产品的故障诊断功能时必须增加自定义部分才能形成完整的诊断协议。因此要获得故障信息，必须知道该厂家的具体协议内容（有些诊断工具开发商通过使用工具监测通讯信息来分析协议内容）。KWP2000协议对于不同的信息设有不同的安全级别。普通的故障信息没有安全保护，只要知道协议，即可通过诊断工具读出。其它方面的信息由ECU生产厂家分为不同的级别**访问，需通过安全认证过程才能获得这些信息。安全认证过程通常通过“种子”，“密匙”进行验证。

　　6、如果开发一套类似与奥迪VAS-5051B功能的软件，计算机和汽车故障诊断接口之间通讯的原理是什么(就以大众车系为例)，需要怎么样连接?我在网上看到有人叫卖VAG-COM连接线，能用吗?

　　答：从PC到诊断接口的连接需要电平转换，也就是从K-Line到RS-232电平的转换，至少需要一块IC。我不知道你说的连接线是什么结构，有没有用我不好说。

　　通讯原理遵循KWP2000。但如果你看了KWP2000，你会发现其实它只是一个大纲，具体功能需要使用者自己定义，对奥迪来说就是大众。我相信具体的通讯协议你是拿不到的。

　　你所下载的VAS-5051B应该只有很低的安全级别，只能实现很少的功能。高安全级别的通讯有软加密和硬加密。

　　顺便说一句，汽车的诊断有很多牵扯到整车安全，这也就是为什么大众要保密。你小心不要费了半天劲做了个非法的东西。

　　7、CAN总线与MIC总线性能对比！

　　答1：MIC总线是专门为解决恶劣的军事环境(包括核辐射)中电力及数据分配和管理问题而开发的一种简单的高可靠性时间分割多路传输串行现场数据总线。CAN总线开始也是为军事服务，在成本得到认可后，才开始应用于工业控制和汽车电子。两者同样适用于恶劣环境，但手段不一样（底层硬件应用协议），达到的目的也不一样。MIC时间分割多路传输，双冗余串行通信的方式传输数据，比较适合尖峰脉冲干扰频繁的场合。CAN可以简单的理解为差分信号，对浪泳等共模干扰抑制能力很强。当然，如果你不介意数据冗余，485，LIN也是不错的选择。这个前提是距离不要太远。

　　答2：应用目标是汽车电子设计，这是基础。在距离来看，车上的线束还没有超过40米的。在电磁兼容角度来看，要符合ISO7637的要求。好了，标准已经清楚，现在我们开始讨论。

　　1两种总线体系结构比较：这里已经说的很明白很具体了，我只补充一点。

　　a、节点一般可达110个：其实根据不同的应用芯片，差别很大的，通过网关的扩展那就没谱了。在汽车电子应用来看你能用到几个节点呢？非常有限的。

　　b、多主式结构制约了通信的实时性，也会导致数据的拥堵：反对！所有的串行通讯都是队列呀，CAN是硬件底层协议保证队列，应用层协议保证实时性，堵不起来的。

　　2性能比较

　　实时性：CAN总线实时性不如MIC总线。这是队列和应用层协议的问题，您的观点的基础是MIC有序而CAN无序的前提。结论自然错误。可靠性：无论是MIC还是CAN，出故障的模块都会死掉。而对网络管理来讲，CAN不需要任何处理，MIC在主控死掉的情况，要麻烦一些。如果考虑到接替问题，那就不叫优越性了。传输特性：其实如果在40米的极限距离来讲，讨论的有啥意义呢？

　　3应用场合比较

　　如果讲坦克、军用车辆，无语了。为了保障军车在核爆后的存活率，都是很原始的东西。例如仪表，连数**管都不给用。

　　8、基于CAN总线来对车上的电子设备/ECU等等进行在线测试,是一个大方向，可否详细介绍一下这方面的测试技术和标准的设计思想？

　　答：测试标准分为软件测试和物理层测试：

　　物理层测试也分为两个部份，一个部份是细化了J1939对物理层的测试方法，第二个部份是有一定的创造性的它包括信号完整性测试，物理层的时延测试和EMC测试。

　　软件测试，软件测试包括通信的实时性测试和软件对通信错误处理能力的测试。

　　关于CAN的测试，我前前后花了一年多的时间，现在还没有完全，而且内容多，不可能一下子公布，有些还涉及到其它方面的问题。

　　CAN开发应该分为两个阶段，一个阶段是功能开发，另一个阶段是性能开发。

　　1CAN的功能开发，就是指能否利用CAN传输消息，即CAN调通没有调通。这个我就不说了，可以说现在大家干的基本上都在这一层次上。

　　2CAN的性能开发。CAN的性能开发又分为两个阶段，其一是物理层设计，其二是CAN信息的实时性。

　　2.1CAN物理层设计，CAN的物理层设计主要涉及两个方面CAN的传输时延和EMC。大家知道CAN的传输距离和抗干扰能力主要由信号的传输时延决定的，当CAN发送消息后，在规定的时间内接收不到ACK就认为传输失败，这和RS485通信是有本质的区别的。在物理层的实际设计过程中，为了增强CAN的抗干扰能力必定要加光耦，电容，TVS和电感类拟的东西，这些东西的加入无形中要增大信号的时延，本来为了增强CAN的抗干扰能，由于传输时延的增加，反而降低了CAN的抗干扰能力，这是我在近十几年在国内一些同行设计的CAN系统中发现的问题。目前我设计的CAN系统在500K的通信速率下在J1939的电缆中传输100M都不会发生错误;而前几天国内一家比较有实力的单位设计CAN系统在125K的通信速率下仅能传输几十米。同时我也测试过BOSCH的产品，其性能是非常高的。所以我在863电动汽车重大专项的总线会议上经常强调要设计一个具有竞争力的CAN系统，并不是简单地使用82C250，与82C250相关的每一个电阻，电容，电感和PCB上的每一根线都要认真考虑。对CAN的物理层设计的评估有一套方法，在这套方法的测试下就能分清优劣。

　　我为什么要研究CAN的测试方法，这是因为在前年我参观专项中一次CAN联调，发现总有一些CAN节点不能正常通信，而所有的零部件单位都说他们的没有问题，这时谁也不知道这是谁的问题。为了解决这些问题于是我开始CAN测试方面的工作，没有想到这一干就是两年。

　　2.2CAN的实时性测试是指CAN的消息是否能准时发送。由于CAN自身存在优先级反转和软件开人员水平的**，特别容易出现消息的周期抖动(jitter)，我在测试中发现一家零部件研发单位采用POWERPC作为ECU的CPU，其CPU的负载很低，但他发送一条周期为10ms的消息，有时需要100多ms才发送出来，有时还不到5ms就发出来了。如果在CAN系统中出现这样一条消息，我想CAN的通信功能都实现了，但其控制质量肯定得不到保证。

　　对于CAN的测试技术是否成熟，我一直认为国外从事发动机，制动和变速控制的研发公司都有严格而完善的测试方法和标准，但我们得不到(也可能包括在华的合资和独资企业，因为如果在华的合资和独资企业有，我们也可能通过各种方式了解到)。这就需要我们去探索。

　　实际上CAN的测试设备有的很贵，需要买，但很多可以用现有的通用设备和自制。

　　9、就目前国内车载网络总线发展的状况而言，CAN应该是主流，接触CAN的机会比较多，请问CAN网络的测试规范和标准该如何制定？

　　答：各个大汽车公司针对自己的车载CAN网络制定了各自的测试规范和标准，归纳起来可以分为：

　　1、正常的通讯测试

　　2、电气稳定性测试

　　3、故障情况下的CAN通讯测试

　　测试需要覆盖物理层、数据链路层、交互层、网络管理层等内容。

　　10、CAN系统设计的关键点分析

　　答：我们是一群通信电子行业的工程师.经过一段时间的观察和分析，我们发现CAN网络的设计和构建并不是十分困难的。关键点如下：

　　1首先要清楚地认识到，CAN网络是一个由多个网络节点(由各ecu控制)组成的无中心分布式网络。这种特性决定了整个网络的行为模式与整车设计关系不大，更多地是由网络上各部件(如，发动机，ABS等)的通信接口(API)相关。所以整车厂商一旦选定了部件供应商，网络的需求和特性就基本确定了。我在论坛里看见整车厂代表和部件厂代表争吵不休，还经常感叹各大整车厂商垄断应用层协议，颇感不解。粗粗阅读OSEK/VDX的相关文件，发觉其中已涵盖各种应用协议。只要知道了各部件的特性，就没有什么秘密可言。

　　2CAN网络对环境的要求比较高，高低温，震动和电磁兼容等特性必须过关。如果有比较丰富的电子系统产品设计经验，这些也是不难搞定的。

　　3CAN网络的基本硬件平台和底层协议已有成熟的解决方案，不必花费太大的时间和精力。

　　4CAN网络的网络管理可能涉及比较大的工作量。因为网络的容错纠错能力，设备的管理能力，网络冗余度的处理等需要花不少功夫。

　　综上所述，CAN网络的设计和实现并不存在不可逾越的技术障碍。只要投入时间和金钱，还是很有希望在近一两年内实现。

　　11、能否描述一下CAN控制器的节点状态处理过程，如节点的状态，各状态之间是如何转换的？

　　答：目前仅有看到OSEK/VDX的NM有规范叙述到节点状态机制，实际上，规范内也制定了一些API，而发展OSEK/VDX实现工具也有支持这些状态机制。

　　网络状态不过也就区分DirectNM和IndirectNM，说穿了不过节点Sleep、Awake，和Suspended之间状态机制的互换，那什么时候和条件下，要转换到相对应的机制上，也很简单，直接看看OSEKNM可以很快的明白，对了别去看OSEKOS和COM，整套OSEK标准让我看到很想去死。

　　实现方面，可以藉由Simulink发展状态机器模型，产生ANSICCode，移植到所发展的MCU上。

　　Actually，未来AutoSAR也会对网络状态进行规范，并且ThirdParty发展厂商也会提供相对应的API。如果，你仅是要自行设计小型网络，套用节点状态机制管理，或许可以参考OSEK的NM去启发你设计的SourceCode。

　　目前，OSEK/VDX实现工具厂商仅有几家，FreescaleOSEKturbo、3Soft，不过都要价不匪。并且，因应AutoSAR的问世，这些工具的Maintance这些厂商也都未再继续维护。但是，读读OSEK会让你发现另外一片新的视野。

　　12、我们是搞车载娱乐系统的，虽然目前国产车的娱乐系统还很落后、还没有与总线接口，但随着CAN等总线应用的不断普及，娱乐系统与其接口只是时间问题。借助这个平台想多了解一些CAN总线的知识，例如：CAN总线的主要功能及特点，娱乐系统与其接口的技术规范，测试方法等。

　　答：对于总线的应用，娱乐系统我认为应该分为两个部分，其一是娱乐控制部分，其二是娱乐数据的传输。

　　对于娱乐控制部分，CAN，LIN和VAN在实际中都有应用，方向盘上的开关（娱乐），基本上都是采用总线，从成本控制上来说，LIN都能满足要求，但具体情况要由主机厂定。

　　在娱乐数据的传输部分，按理说应该用MOST与IDB1394之类，虽然早期有个CAN传输娱乐数据的国际标准，但后来没有影了。但在实际应用中，就有用CAN传输声音数据的。

　　我个人认为，国内开发娱乐系统的厂家应该在其新开发的装置上有CAN\LIN接口，同时还应考虑CPU的资源。

　　至于测试，内容大多，一下谈不清，有机会我们再交互。至于标准，好像现在还没有通用的。

　　节点式娱乐系统一般是双uP结构，有个单独的控制uP。

　　如果不是很复杂的话，音视频数据一般用传统电缆实现。