通过更快速测试，加速产品开发周期：V程序框图导航

机电系统可将能量转换为机械功，反之亦然。它们包含控制电子设备（例如，电子控制单元）或嵌入式控制器（例如，可更换线路单元），并运行专用软件，同时使用来自传感器和其他系统的输入来控制机械、驱动和物理组件。机电系统为飞机、地面车辆和船舶提供推进力以及各种其他功能。  

图1.交通工具类别举例及其中常见的机电系统类型

虽然这些系统的功能、操作方法和设计要求可能截然不同，但交通机电系统的开发和测试遵循相同的工作流程。首先，由系统工程师设计车辆/飞机/船舶并确定其系统、子系统和组件必须满足的要求。然后不同的团队按照规范来开发能够满足这些要求的控制电子设备、软件和机械组件。而这些团队通常各自采用不同的开发流程（通常是针对特定组织需求的常见方法，如Agile）来完成机电系统特定部分的设计和验证步骤。最后，将各个组件集成为一个系统并分阶段测试，最终生产出真车/真机/真船。

图2.机电系统的常规产品开发过程

从需求到设计和验证的过程能以各种方式表示，其中一种方式就是V模型（图3）。即使V模型及许多衍生模型和解释还存在诸多疑点，但是该模型仍是用于检测通用测试架构是否能够满足整个设计的测试需求的一个常用框架。

图3.表示开发过程和相关测试类型的V模型方法

一般而言，V模型的左侧通过渐进式设计决策将高级需求细分为较底层的规范。越来越多的决策采用基于模型的设计方法进行制定，该方法包含各种计算机辅助工程(CAE)工具，具体取决于正在开发的系统类型。有关此主题的更多讨论，请参阅有关数字转换和数字孪生的相关文献。在V模型底部，系统已被分解为最底层的基础组件，设计可随时转换为具体的实现代码，组件原型可以随时构建（并且代码部署到运行软件的原型中，因此V模型底部有时也被标记为“部署”。）V模型的右侧包含的步骤有：将不同的组件集成在一起，根据规格验证其操作，以及根据从基本组件到整机过程中每个集成步骤的要求进行性能验证。

注：在确定系统、子系统和组件的详细信息后，软件、电气组件和机械组件的开发将齐头并进，如图2所示。通常由具备所需领域专业知识的独立设计和测试团队来负责这个开发过程。

注：术语“验证”与“确认”有时可不做明确区分，有时使用总括性术语“V＆V”。通常，“验证”步骤要解决的问题是：“系统的搭建是否正确？”然后根据一系列规范，验证系统在公差或量程范围内能否如预期那样运行。而“确认”步骤要解决的问题是：“搭建的系统是否合适？” 在系统开发完成后，您需要确保系统可以执行预期的任务，并对照一系列需求来测量系统是否具备可接受的性能。

下面按照产品设计过程的顺序大致简要地描述了各个测试的定义，这些测试在实际应用中具有高度迭代性。快速有效地按照V模型完成设计迭代的能力正是领先测试组织的一个竞争优势和关键能力。但也有人指出，V模型的开发过程顺序与瀑布开发模型一样。

MIL测试需要使用软件对控制器和测试对象进行建模。此类测试可以在设计过程的早期进行，以在软件仿真环境中测试控制器策略和系统行为。

SIL测试需要对测试对象进行建模，但是该模型需要连接到实际控制代码，而且这些代码必须使用所选语言编写并在开发机（有时是虚拟机）上编译和执行。

PIL测试类似于SIL测试，但是控制代码必须针对要在实际系统中使用的特定处理器架构和操作系统编写和编译。例如，如果您在具有特定设置的特定FPGA上运行代码，则可以针对这一特定场景编译代码，以确保实际处理架构正常运行并保证足够的资源可用性。这个测试步骤通常独立命名，因为处理架构和硬件的开发非常棘手且耗时，尤其是如果我们要优化电子控制单元(ECU)的设计，通常会导致软件功能和性能受限，需要取舍。

RCP通过在实时控制器和/或是在通过真实I/O连接到实际测试对象的FPGA上运行数学模型，快速迭代可能的控制方案。

HIL是使用仿真的物理组件和传感器在实际嵌入式控制器上进行的软件测试，因此ECU在真实的负载电平下执行真正的电气I/O（包括信号调理），并具有插入故障的能力。

物理测试应用使用基于换能器的测量（例如温度、压力、应力/应变、声音、加速度、位移等）来测试待测组件或系统的物理特性。应用场景包括噪声、振动和粗糙度(NVH)测试，这类测试需要使用麦克风和加速度计进行声音和振动测量。另一个例子是耐久性测试/生命周期测试（高加速寿命测试或HALT，以及高加速应力筛选或HASS），其重点在于确定DUT在各种不同预期操作条件下的行为。

1. V模型的整个右侧强调不同级别的集成测试。集成通常涉及使用两种主要类型的系统：
   测试台 - 用于进行各种组件集成到单个（子）系统的系统级测试。测试台非常适合处理各种可能的测试，因为它们将各种基础组件集成到一个正常运行的功能性系统中。而使用正常运行的功能性系统可帮助工程师有效地配置和执行测试。
2. 系统集成实验室或“铁鸟”- 用于将多个子系统集成起来，以进行整车/机/船测试，近似于在实际汽车/飞机/轮船布局和系统连接中进行测试。“铁鸟”用于系统群测试和系统间通信/交互/边界条件测试。某些测试用例只能使用这么大规模的基础架构才能进行测试。这也是真正为现场/飞行测试/试航开发原型机之前的最后一级测试。

MRO或基地测试旨在为飞机系统提供服务、维修和升级，以确保飞机系统能够多年或多代服役。有时，系统测试台使用与飞机系统相同的设备或升级版设备。而MRO测试的一个挑战是在面对测试系统硬件和软件过时问题、人员更替以及由于定期系统升级而导致需求变化的情况下仍能够在整个项目周期中有效地维持测试能力。 

由于现场测试的成本非常高昂，因此用于现场测试的样机通常装备大量仪器，以提供尽可能多地获取飞机的运行数据。在选择测试仪器的时候，主要的考量因素包括重量/大小、为测试设备供电的能力以及数据存储和检索。虽然现场测试需要大量时间而且成本高，但其仍然是产品开发过程的关键部分，因为模型永远不可能完美无缺，而且系统之间和内部的交互非常复杂，可能会出现测试过程中未涉及的意外行为。现场测试有助于确定飞机是否可以投入运行。

在熟悉了开发过程和相关的测试类型，我们就非常清楚统一测试架构的潜在优势。统一的测试平台可满足整个设计周期内（从早期原型验证到软件、电气和机械验证，再到系统级测试单元和系统集成实验）的各种测试需求，因此测试开发速度和资源利用率将大大提高。而且整个V模型各阶段之间和项目之间的设备和人员也更具互操作性和可互换性。从测试能力和迭代方面来说，工程师将能够更快速、更轻松地完成V模型每个阶段，这一点无疑非常有价值。

统一的测试架构的优势类似于面向对象编程模型。如果您经常需要使用相似的方法开发相同类型的系统，完全可以投资开发一个核心的系统，这个系统应该可以跨项目使用，而且可以根据每个项目的独特要求进行自定义。 

而且这种基于平台的测试方法更加强大，因为其测试架构是以灵活且可扩展的平台为基础，因此您绝对有自信，就系统功能和测试能力方面而言，您绝对可以满足不断变化的需求和各种预期之外的系统需求。或者，换句话说，采用这种方法，您就无需非常明确地设计系统功能，从而灵活地应对未知的情况以及预测未来的需求。这比专用的固定功能的系统要好得多，因为在这类系统中，您需要明确地规划和设计您认为将来可能需要的灵活性和可扩展性。这些功能固定的系统会迫使您在时间和成本以及功能和性能之间进行权衡。

在开发过程中我们需要尽可能早地“预加载”尽可能多的测试，以更快地进行迭代并确保更经济、更安全的测试。这时可以在实验室中使用基于模型的控制和仿真来充分模拟各种激励和真实条件。这样以前只能通过现场测试进行的分析就可以转移到系统集成实验室或系统级测试平台上。现在有一些技术可以用来改进这类测试，比如通过模型控制的致动，在现场记录真实激励信号，然后到系统上进行“回放”。
另外，如果您的测试需要用到其他团队的组件，就可以通过仿真的组件来进行测试，无需再配合其他团队的进度。但是为了确保足够的测试结果保真度，您必须花时间验证组件仿真所使用的模型和方法足够准确和有效。
基于模型的控制和仿真提供的另一个好处是能够更好地测试难以复制、危险和极端的测试用例。这提高了测试覆盖率，让工程师对设计更有信心。

有时要实现特定功能的时候，能够选择的传感器、执行器、仪器或软件的类型或品牌并不多。在测试系统的设计成本中，光是让所有不同部分能够相互支持所需的成本就占了一大部分，尤其是在改造或重新设计传统测试系统时老化系统组件的处理。如果测试平台提供各种I/O和第三方设备功能，那么就可以最大程度提高复用率，最小化集成所需的工作，从而大幅提高测试效率。此外，采用可配置或可扩展的分布式/同步I/O架构可以满足整个设计过程中不同测试用例的各种I/O需求，并实现跨项目复用。

随着测量速率的不断提高，测量需求的不断增加，数据量无疑呈爆炸式增长，数据格式也变得更加丰富多样。越来越多的客户需要在整个设计周期中访问各种类型的测试数据，来满足更多的报表需求。而确保数据的可用性以及真正有效利用这些数据本身就极具挑战性。您需要能够有效地查找和加载数据，以交互方式实现数据可视化及数据分析，并通过自动生成报表来尽可能节省时间。因此，统一的测试架构必须提供企业级且易于IT支持的数据管理和系统管理框架，来优化决策制定，减少重复测试、报表生成时间和工作量，并使数据成为资产而非负债，从而尽可能提高设备利用率和正常运行时间。

现在，开发和测试团队通常遍布全球，这些团队发现有效地跨站点管理测试系统以及将各个站点生成的数据关联起来越发困难。有效管理分布式测试系统和数据有助于提高运营洞察力、减少停机时间和提高生成数据的可信度，从而节省大量成本。

因此，以软件定义的测试平台为基础的统一测试架构无疑是团队设计和测试先进交通机电系统的最佳选择。与完全内部定制开发或完全一站式外包解决方案相比，这种方法可以加快测试开发速度，提高测试覆盖率和运营效率，让团队更灵活、更强大，降低资本支出以及提高长期测试系统的正常运行时间和可维护性。