在当今的轿车电子开发进程中，测验扮演着十分重要的人物。可是，在运用正确的战略、思维和东西以使将来完结更为高效和主动化履行测验方面，业界依然有许多潜力可挖。本文剖析了测验技能的现状，阐清楚在实践中所产生的交互作用疑难问题，而且证清楚今日现已能够运用现成的东西以一种高雅而高效的办法处理与测验相关的详细项目使命。
1.导言
曩昔十年，轿车电子职业的状况产生了天翻地覆的改动。起先，在轿车上仅运用了几个ECU，可是现在某些豪华车装置的ECU数量现已超越[JW1]了60个。增加的电子体系进步了安全性、舒适性并节省了动力。今日，更多的立异依赖于电子技能，而许多功用的完结也日益依赖于软件。
杂乱度的进步使得全面而高效的测验变得比以往任何时候都愈加重要。许多电子元件的广泛运用导致潜在过错源的数量急剧增多。由于测验能够尽早发现并改正过错和降低本钱，因而不管在ECU开发的哪个一切阶段它都是不可或缺的。此外，只需将部件集成起来并作业于实在环境和实时条件下时，一些体系缺点才会露出出来。这让测验成为了一门跨部分和跨厂商的学科。
前期产生的许多电子毛病阐明，在不考虑上述事实且忽视体系测验的状况下会产生什么问题。问题发现的越晚，对举高本钱产生的影响就越严峻。而极点状况下由于批改过错而引起的产品召回愈加清楚地阐清楚这一点。虽然轿车工业的成员吸取了这些经历，对测验极为注重，可是咱们依然能够经过现有的资源来进一步进步测验功率。此外，虽然测验本钱占用了项目预算大部分资源，但它确保了ECU的正确功用。因而，运用清楚的概念(比方运用现代办法和东西替代不全面的主动测验进程)来最大化的进步测验质量和测验深度是十分重要的。
2.剖析、仿真和测验东西
ECU网络是轿车电子的中枢。而剩余总线仿真办法为进行ECU测验树立了重要根底。假如没有对ECU环境的开始模仿，那么大多数ECU都不能有用地地作业。比方，许多ECU只需在供给网络办理功用的条件下才干正常作业。
来自Vector Informatik公司的CANoe是一款被广泛用于剖析、仿真和测验分布式、嵌入式体系的东西(图1)。它被广泛使用于剩余总线仿真而且支撑一切重要的总线体系――特别是CAN、LIN、MOST和FlexRay――Vector Informatik公司也供给适用于这些总线体系的PC接口。现有的商业接口卡可用于从CANoe拜访ECU的I/O线路。此外，Vector还宣告将发布一种带有特定测验功用(比方切换附加负载到ECU终端和将其直接短路)的I/O硬件产品。
图1：CANoe包含针对网络体系的剖析、仿真和测验功用。
各种剖析功用、仿真组件和测验序列依赖于以数据库办法集成在东西中的模型。它们或许是用于CAN的DBC格局的通讯矩阵、用于FlexRay的FIBEX文件、用于MOST的XML功用目录或用于 LIN的LDF文件。相同，CDD和ODX描绘文件能够用来描绘ECU的确诊功用。测验描绘文件除了包含体系的根本信息外，还包含了信号、报文和确诊服务等的符号化称号。这简化了测验人员和测验开发者的作业，而且在测验和通讯描绘之间创立了一个笼统层。
任何能作业Windows操作体系的简略 PC作业站都可作业CANoe。运用实时装备体系能够树立具有更高实时功用的、更为强壮的测验站。实时装备体系由两部分组成(图2)：一台作业实时操作体系(Windows CE)的专用电脑，用于履行剩余总线仿真和实践的测验；另一台独立的PC机，用作图形用户界面和进行点评。在该设置中，体系也可用作进行部件HIL测验的测验履行环境。
图2：双机作业的CANoe Real-Time供给了更高的实时性。
3.测验与开发的集成
现在的开发模型在各个开发阶段都要求进行测验(图3)。一般，个别测验是独立的、别离的活动，是由专门的人运用专门的东西、语言和办法在有恰当装备的专用作业站上完结的。这儿，创立测验一般是一项独立的作业，与其他开发活动是分隔的。
图3：测验在一切开发阶段都是不可或缺的。
这种分段式的作业办法源于将开发进程中许多不同的使命分配给专门的作业组。可是，假如对使命切割的要求太严厉，那么不同开发和测验使命间的许多相关点将很有或许不能被优化运用。例如只需很好地和谐部件测验和体系测验才干防止开发过多内容相同的冗余测验用例。当运用兼容东西时，现已开发出来的测验用例能够作为其他不同范畴的开发根底。防止冗余开发的做法释放了占用的资源，举例来说，能够将其投入到现有测验用例及其高档开发的承认作业中。全面的测验办理为协作供给了坚实的根底，共用相同的测验用例优化了测验的广度和深度。和谐也有助于发现和添补测验缺口。
除了衔接不同的测验阶段，开发和测验活动也有必要彼此联络且相互习惯。应当将测验了解为开发的一个组成部分，它需求运用恰当的办法和东西来支撑。在程序和结构上得到确保之外，有必要确保这一点。在此，重要的是测验与开发一同进行，而不是只在要求的正式承认阶段进行。抱负的状况是，能够直接在ECU开发者的作业地址运用现有的资源直接进行测验。
为此，CANoe供给了一个用来履行测验的作业时环境，并能够与剩余总线仿真和剖析功用并行运用。该流程十分简略树立，尤其是在开发者现已运用CANoe进行剩余总线仿真和总线通讯剖析的状况下。
CANoe的测验组件能够手动、半主动和彻底主动化的完结测验。开发者能够从简略测验下手，然后对它们进行扩展和完善。一般，杂乱测验的创立进程是承认部分的使命，他们要在开发者的测验上树立他们的测验。
这种测验的一个重要根底是剩余总线仿真。抱负状况下这种仿真并非由手艺树立，而是从体系的描绘数据库中主动生成和参数化的。实践作业由所谓的建模DLL(比方交互层、网络办理等)完结，它们是随东西一同供给的或许是由Vector作为OEM专用建模包供给的。剩余总线仿真为模仿节点供给的信号能够直接从测验脚本中获取，也能够手艺办法鼓励或增加。
与测验阶段中体系化的方案、履行和归档活动比较，随同开发的测验一般省掉了正式的履行和归档。可是，这些测验对进步全体质量做出了实质性奉献，由于他们赋予了开发者为后续的测验阶段供给更安稳的产品的才能。
4.老练度点评和差错剖析
在开发进程中，为了点评ECU的老练度，需求对一切履行过的测验进行全面的点评。除了要考虑单个测验成果在牢靠性和相关性方面的质量，更重要的是选用恰当的测验来全面掩盖所要求的特性。因而，非正式的测验成果对老练度剖析也是有协助的。前提条件是(除记载测验进程外)运用兼容的装备办理。从完结面向质量的、结构化的开发进程的视点来说，这也是十分必要的。
不管在何时何地(测验实验室或作业台上)，无需用户或测验用例开发人员进行干与，运用CANoe履行测验时都会生成一个测验记载。这样在进行伴有测验的开发时就不需求做额定的作业。用于测验记载的 XML是一种敞开格局，以使其它东西运用以对成果进行更深化的处理。例如在进行老练度剖析时能够运用一个测验办理体系来点评测验记载。
这项作业的实质是测验成果到测验用例、测验用例到需求的映射。运用仅有的标识符(比方一个需求ID)能够很简略地完结这一点，测验用例开发者在单个测验用例中会引证它。CANoe会主动将该标识符复制到测验记载中，这样一切测验用例、测验成果和需求就能够明确地相关起来(图4)。
图4: 测验用例和测验成果由ID明确地引证。
剖析实践产生过错的原因至少与记载和点评测验成果相同重要。大多数测验东西都不会供给这样的功用或许仅供给一些并不完善的功用。一个重要原因便是过错剖析经常被当作开发者的一项彻底独立的使命。首要，他们面对了解测验中检测到的过错并盯梢其原因的问题。尤其是当测验实验室陈述过错时，开发者乃至经常无法运用测验中用到的体系。
依据上述原因，测验台上的测验进程以及每一个与DUT间的交互动作都将被强制记载，特别是总线通讯。在剖析阶段，CANoe答应重放和剖析任何需求的记载（日志）。然后有或许在开发场所运用与测验台上相同的测验体系以从中获益，这样开发者就能够独登时再现生成过错的测验用例。在许多状况下，乃至是有必要进行简化时（比方为了防止挑选不存在的丈量硬件）都能够履行相关测验用例。
5.信号笼统和确诊
笼统是处理软件开发和体系规划中杂乱度问题时遍及选用的重要办法。它也可用来处理测验。ECU中不断增多的功用不只增加了体系的杂乱度，还需求更广泛和杂乱的测验。挑选正确的笼统层组成测验不只会影响创立测验用例所需求的作业量、然后影响本钱，而且会影响测验用例的质量。就像一切其它软件组件相同，测验用例本身也或许会存在过错，应该在运用之前进行查看。此外，还需求必要的保护，比方习惯需求的改动和修订测验用例。
信号层笼统是测验ECU功用的常用办法，这也是为什么在ECU中实践的使用程序一般会依据信号笼统的原因(图5)。例如，在一个CAN体系中，ECU交互层供给了信号笼统。这正是CANoe运用交互层的办法；运用网络描绘中的信息，它将本身参数化。网络描绘相同也可用于创立ECU软件。这确保了ECU和测验环境运用相同的笼统层然后在两者间构成最佳的和谐。
信号笼统也标明了――至少在协议层――剩余总线仿真。比方，它确保周期性信号的确是按周期发送的。在测验中，ECU是假定置于总线通讯的实在环境下的。此外，当修改了体系通讯矩阵时，一般能够继续运用坚持不变的测验用例。对相同的使用程序，笼统使得类似项目中的测验用例得到复用。
图5: 信号一方面供给了音讯和I/O线路间的笼统，另一方面供给了测验界说和仿真模型间的笼统。
在ECU测验中，重要的并不只仅是信号接口。只需在对ECU进行较深层拜访时，对许多ECU功用的测验才会有意义。这样的拜访是由确诊和标定接口供给的，它们经过ECU的现有总线接口接入。由于在通讯进程下已有既定的协议，运用简略的音讯序列对这些接口进行拜访是没有意义的。而运用恰当的确诊和标定笼统才会愈加便当与牢靠。
在CANoe中，由来自CANdela东西的描绘文件或许ODX描绘文件担任确诊拜访层的参数化。假如没有对ECU实践确诊才能的描绘，则可运用CANoe供给的针对KWP2000和UDS的一般描绘。ECU专用的一般描绘文件或确诊描绘文件都为便当地拜访那里界说的确诊服务供给了便当，开发人员或许会获得与上文信号笼统中相同的笼统数据和长处。
经过CANoe中的测验脚本就能够运用丈量与标定协议CCP和XCP来拜访ECU的内部变量。丈量和标定东西CANape处理这些协议和需求的ECU描绘文件(A2L)。 CANoe经过COM接口操控CANape。这样就到达了与上文的信号笼统及确诊笼统中相同的方针。
6.高效的测验生成
对测验用例的深化研究标明：许多测验用例能够仅从几个循环方法中生成。这种状况在网关ECU中尤为显着：大多数测验用例用于查看信号和报文的路由。也便是说，运用许多测验用例的仅有原因是存在着许多或许的输入和输出数据。可是相同类型的方法也存在于其他类型的ECU中。这意味着许多功用的测验都是如此进行的：首要运用适宜的鼓励使ECU进入一个特别状况，然后查看进入的状况。这种测验用例的循环方法是：设置信号（鼓励），等候最大容许呼应时刻，然后查看新ECU状况下的信号。依据运用测验方法的经历，用户或许辨认几个附加的作业时方法，并从中生成许多测验用例。
上述方法标明，测验用例的生成还有被进一步优化的时机。除了供给典型的测验用例编程外，CANoe还为用户供给了依据测验方法来界说测验用例的办法。由于测验进程是已知的而且已被集成在了供给的方法中，所以就没有必要再对方法内容进行编程了(图6)。这样一来测验用例的生成就被简化为界说方针行为，包含任何需求的弥补数据，比方答应的树立时刻。
图6：运用方法笼统了测验用例的实践履行然后简化了测验开发。
很显着，供给的测验方法坐落前文所述的信号笼统之上，凭借相关的数据库赋予了对信号、报文等符号化拜访的才能，而且将运用确诊服务或I/O信号也变成了或许。简言之：整个CANoe的测验底层结构可与测验方法共用。假如真的有需求超出了这些才能，还能够挑选对测验用例进行编程。
测验用例的主动生成是在有适宜信息源的状况下有用创立测验的另一种办法。虽然生成的测验内容必定受限于描绘水平缓来历的深度。可是当经过测验掩盖正式界说的ECU根本特性时，这种测验却供给了适当有价值的支撑。生成测验需求很少数的作业，这就使得测验能更快的进行，然后更早地发现问题。
图7: 运用生成器能够从彻底不同的来历创立测验。
Vector的东西链运用了这种测验生成器的办法。比方DBC数据库或CANdela界说等描绘文件是生成器的资源(图7)。在运用这些文件生成测验用例之后，CANoe就能够当即履行了。由于测验脚本或许运用整个东西的底层结构，所以测验生成器一般都规划的十分简略。比方只需少数的作业生成器就能够从用户界说的网关描绘(例如数据库办法或 Excel电子表格)中创立恰当的测验用例。凭借前文讲到的测验方法，从客户的特定数据到测验方法格局中心只需一步简略的转化。用户可直接创立这样的生成器。Vector以项目服务的办法供给进一步的支撑。
7.总结
轿车OEM和供货商应对增加的ECU测验需求的仅有途径是高效地创立测验和主动化履行测验。本文介绍的测验东西供给了一种被证明的、运用信号笼统/确诊/标定/I/O接口的集成、测验方法概念和测验用例生成器来完结测验使命的处理方案。CANoe是一个测验ECU和网络的高功用实时作业环境。测验开发人员只需在自己的作业台就能在前期创立和履行测验，且仅需做少数作业。CANoe的敞开接口促进了全面的测验战略以及东西支撑的测验办理的无缝集成。虽然一些用户还把它当作一种前景想象，但只需恰当地集成CANoe，或许这种技能在今日就能够到达老练水平了。Vector正在继续地开发CANoe以习惯上述范畴的使用，并为用户供给现代而高效的测验渠道支撑。
