随着汽车开发中LIN控制器产品数目显著增加，有效的LIN总线测试方法变得愈加重要。高质量和高可靠性是保证总线系统成功应用于现代汽车的基本前提。依据最新的LIN一致性测试规范，Vector描述了当前LIN节点测试的可行方法。对于主节点，基于开发、仿真工具，提出了一种全新、有效的黑盒测试方法。

1 引言

对于各版LIN协议规范，LIN协会都为之制定了相应的一致性测试规范。一致性测试一方面用于验证LIN设备是否遵循相应版本的协议，另一方面也是鉴定LIN产品是否合格的基准。由于LIN网络为主/从工作方式，因此主节点的协议一致性就变得尤其重要。LIN一致性测试依据各OSI层分层规定，包括：物理层，数据链路层，网络管理和节点配置，只有应用层测试需要OEM(整车厂)或供应商具体制定。

黑盒测试由于只需使用设备的外部接口(LIN接口)来实现激励和验证各测试用例，因此它成为有序执行一致性测试的最佳方法。相比之下，白盒测试需要访问设备的内部接口(LIN驱动程序标准接口)。目前相对于CAN通信，LIN主节点通过外部接口只提供非常有限的激励选择。灰盒测试结合了以上两种测试方法，因此成为当前实现LIN主节点一致性测试最普及的方法，如图1所示。

目前，LIN主节点一致性测试通常按照灰盒测试方法执行；然而黑盒测试将是更可取的。

2 LIN一致性测试的环境

典型的ECU测试用例需要对测试系统和被测ECU执行配置和初始化，以及随后的激励和验证。Vector公司提供的从节点的一致性测试几乎完全按照黑盒测试实现，测试设备作为主节点可以直接通过LIN总线执行激励和验证。只有一部分测试需要人为进行激励和验证，例如：触发产生一个唤醒信号。而另一方面，主节点一致性测试则按照灰盒测试实现，测试设备由Vector斯图加特总部提供。该方法需要专门用于测试的LIN描述文件(LIN Description File，LDF)，以确保主节点驱动程序的正确配置。同时，测试程序必须和驱动程序代码一起，下载到被测主节点中。这样，虽然测试工具的角色是从节点，但仍可以通过LIN总线实现激励和验证。

位于波兰的克拉科夫的德尔福技术中心在采用实现LIN2.0和J2602测试领域，已经积累了丰富的经验。鉴于LIN一致性测试不包括OSI的应用层，该技术中心已将其测试进行扩展，包括了各种应用层测试。这些测试主要针对：信号、调度表、网关路由和诊断。CANoe提供的CAPL测试功能已被证明是实现和自动执行这些测试必不可少的部分。德尔福技术中心的工程师们认为，使用类似于C语言的CAPL，可以方便的实现和扩展高复杂度的测试用例。

图1：灰盒测试与黑盒测试。

3 主节点灰盒测试的缺点

关于可行性方面，采用灰盒测试实现主节点一致性测试存在一些缺点，例如不能在开发的所有阶段执行测试。而且，在进行主节点测试前，还需要一些必要的准备工作，例如ECU配置和依据用于测试的LDF生成主节点驱动程序。

采用灰盒测试实现的主节点测试，允许LIN总线经由测试程序间接的访问主节点驱动程序。尽管这样可以完成所有的测试，但这种方式意味着不能严格遵循通用的V模式开发流程。例如，只能在开发的最初阶段验证主节点的一致性，一旦主节点运行了产品级的LDF和应用程序，进一步的验证工作就不容易实现了。而且，没有供应商的协助，OEM不能重复主节点相应的一致性测试。

4 主节点黑盒测试的实现

鉴于灰盒测试存在以上不足，许多汽车OEM和供应商提出主节点一致性测试能否采用黑盒测试实现。黑盒测试最大优点是：OEM和供应商在开发的整个阶段只需简单配置工作即可独立执行测试。

然而，为了真正发挥主节点黑盒测试的优势，首先还需要满足一些要求，其中可能最重要一点是要求用于开发和测试的驱动软件相同。实现这项要求的一种方式是扩展主节点的驱动程序，提供专用的测试接口。

扩展驱动程序，必须允许测试设备使用专用的测试服务，并通过LIN总线实现对被测主节点直接的激励和验证。例如，这些测试服务包括修改调度表，或者读取驱动程序的状态字等。和配置服务一样，主节点和测试设备之间的通信采用专用的诊断服务。扩展驱动程序的进一步要求是最小程度的增加ECU资源的占用，同时要求测试程序可以通过预处理程序定义等方式从产品用代码中移除。

5 LIN 2.x 黑盒测试原型

按照OEM要求，Vector的LIN专家设计了一种用于主节点一致性测试的黑盒测试。在制定测试原型的规范说明过程中，测试通信显然不能对主节点的正常运行产生负面影响。满足该要求唯一的解决途径是通过使用标准的LIN诊断方式实现(包括请求和响应)，而服务则采用一种新的专用的诊断服务。只有这样，才能实现由作为从节点的测试工具来初始化通信(而不是主节点)。当测试工具向主节点发送测试命令时，主节点可以发送肯定或否定响应，如图2所示。测试通信需要识别出主节点一致性测试中执行的是黑盒测试。

图2：黑盒测试通信过程。

在发送每个测试命令前，必须执行测试联机操作和初始化。这产生了一个问题：主节点的一致性测试如何独立运行于常规应用程序。实际上，完全的独立运行或并行都是不可能的，在测试中必定包含应用程序。

为了解决应用程序和驱动测试程序的交互，这里有两种基本的方法，如图3所示：一种方法是明确地通知应用程序正在执行测试。另一种方式是尽可能的在应用程序中隐藏测试程序的执行。两种策略各有其优缺点，最终方法的选择取决于主节点ECU供应商的反馈意见。两种方法中，都需要扩展当前的驱动程序以支持必需的测试服务。根据评估，附加的代码量大约为实现LIN 2.x 协议代码的20~30%，这对于大部分主节点ECU都不会产生问题。

图3：解决主节点应用程序和测试交互作用的两种策略。

当前实现的原型共提供11个服务，足够满足LIN 2.0主节点的一致性测试要求，如图4所示。由于Vector倡导的方式基于当前的LIN开发流程和协议规范，所以它不仅具有可扩展性，更便于标准化。

图4：LIN 2.0 主节点一致性测试11条测试命令。

6 展望

除了这些工作，Vector计划进一步开发。例如，如果2008年第二季度颁布LIN 2.1的测试规范，那么Vector在2008年第三季度发布的7.0版本SP 4/5将支持LIN 2.1 从节点测试，第四季度发布的7.1版本将支持LIN 2.1 主节点测试。另外，除了开发、分析和仿真工具，斯图加特总部还提供有关CAN、LIN、MOST和FlexRay网络各个方面的培训和研讨会。借助大量的项目合作， OEM和供应商可以直接获益于Vector 20年的网络开发经验，并在Vector获得专业的技术。