Significant Test Time Reduction and Equipment Utilization in 5G RF Production Testing

Sascha Laumann，罗德与施瓦茨，德国慕尼黑

（点此阅读含图表的全文）

随着部署步伐的加快，5G基站和基础设施制造目前已成为通信技术中最热门的领域之一。通常，我们所在的竞争行业仍在以传统的指标衡量成功，例如生产和集成成本、生产率和上市时间等。然而，随着5G基础设施大规模建设的开始，能否满足大量的产品交付已逐渐成为成功与否最为关键的因素，交付瓶颈或可导致惨重的业务损失。问题是，“我们如何在已知的技术和经济条件下加快产品生产？”这个问题的答案可能不止一种。但针对生产测试，答案很可能就是：“在给定时间内，按照规范要求提高正常生产以及成功测试的产品数量。”

自测试工作开始之初，提升“测试速度”就已经成为行业持续关注的热点课题。产品发布频率的持续加快、上市周期的缩短以及预算限制都要求从业者对如何改进生产环境中极其重要的基本指标之一提出新的思路，而这里所说的指标就是测试吞吐量。

测试吞吐量的实质是测试速度的倒数。除了能够表示单个测试的执行速度外，测试吞吐量还可以体现并行执行多个测试的情况。想要实现更高的吞吐量，并行操作往往必不可少，当提升单次测试的速度在技术上无法实现或是成本太高的情形下尤其如此。并行操作的形式有很多种，它可以是简单的复制，也可以是独立执行的任务和允许完全异步测试执行的子任务的组合配置。在这种高度并行化的测试环境中，几乎没有办法去衡量测试速度。但相对而言，测试吞吐量仍然是一个有效指标，其重要性也日益凸显。

测试并行化的实施必须经过深思熟虑；实现更高的吞吐率，绝不能以牺牲任何质量指标为代价。异步执行的测试越多，就需要在确保测试结果的有效性和一致性上投入越多精力。专用于顺序执行的解决方案并不一定适合并行操作。幸运的是，软件架构领域的技术进步使得测试范式的这种转变成为可能，并且不会影响到测试质量和重复性。目前，市场上已有成熟的并行操作解决方案。

问题描述

在新兴的5G基础设施业务背景下，确保高生产吞吐率对企业成功和保持市场竞争力至关重要。显然，测试吞吐量只是影响生产吞吐量的众多因素之一，然而，相较于其它指标而言，在特定条件下改进这项指标更为容易，所需的先决条件也并不多。

通常，5G生产测试是在产品装配线附近或与之结合执行的。产品组装完成后，将执行一系列手动或自动测试，包括射频测试。执行测试后，系统会根据测试结果判定被测设备(DUT)是否满足测试要求。最后，系统会对测试的产品进行相应的分类。以上便是顺序和同步测试执行的典型示例，下一项任务必须在当前任务已结束且结果已知后才能进行。通常情况下，射频测试对系统整体性能没有太大影响，但测试数据分析会随着测试条件严格化而更加复杂，因此，改善测试吞吐量非常必要。

顺序执行因其简单特点而被广泛应用于各种应用当中，但它也存在一个潜在的重大发展障碍：通常无法很好地进行扩展。在这种情况下，想要增加吞吐量只有两个选项：安装一个或更多的生产和测试设备或降低测试的复杂程度。前者无疑会增加成本；后者则可能导致总产量下降或加大设备在运行中出现故障的概率。

让我们回到5G基础设施制造和测试用例，3GPP TS38.141规格要求对多项指标进行评估。用于确定某一DUT能否通过测试的常用度量包括：误差矢量幅度(VEM)、频谱模板(OBUE)/频谱发射模板(SEM)以及邻道泄漏功率比(ACLR)。所有测试在多个频率和输出功率范围内联合执行，测试的深度和数量取决于产品分类及其规格。

在5G宏蜂窝基站执行典型的生产线测试可能需要耗费几分钟的时间。加快这一进程能够有效提升生产吞吐率。而重复的特性测试可能需要测试场景数小时才能完成。若是对设备生产和测试的复杂过程进行分析，不难发现其中一些任务或子任务执行得并不理想。因设备所需测试的产品和测试规格而异，时间主要耗费在测试数据收集或分析上面。显然，未来的5G FR2测试（以及之后的测试）所提出的更高要求很可能会继续加大分析的复杂性，从而进一步延长处理所需的时间。

背景

并行化在技术和生产力优化领域并不是一个新概念。在过去的几十年中，并行处理单元（多核CPU）的数量不断增加，而且从编程和操作角度可简化对这些资源的访问，这些进一步推动了并行化的发展。近年来，随着分布式系统的兴起，异步和异步操作变得备受关注。它为实现非确定性操作构建了一个基础结构，主要应用于通信技术当中。

并行化在技术领域的兴起催生了新的问题解决方法：并行化并不专注于提升单个执行的性能，而是将执行的可扩展性提升到了一个新的水平。纵观当前现有的基于云的技术，我们不难发现，在允许并行处理的框架下实现性能提升将更为简单。

从经济角度来看，并行化的需求也在上升。优化资产（如测试设备）的使用成本变得愈发重要，在需要巨额投资的情况下尤其如此。投资回报率(ROI)以及总体拥有成本(TCO)等相关指标的重要性也在与日俱增。最后，运营支出(OPEX)等新的业务和成本模型也要求企业进一步降低前期费用。这种情况下，不同的商业解决方案的出现可谓众望所归。而这一切反过来又增加了合格设备使用指标的重要性，该指标的存在让解决方案提供商和他们的客户都更加倾心于基于使用量的业务模型（如计次付费）。

方法

顺序操作

让我们假设以下场景：操作人员需要对DUT进行一系列特定测试以确保其功能正常。如图1所示，我们假设每个单独的测试顺序均包含五个子任务：测试准备和设备设置、激励生成和数据捕获、测试数据检索（传输）、数据处理/分析以及测试结果交付。操作人员可以通过一组不同的测试参数或通过预配另一个DUT来重复测试顺序。

图1：顺序测试场景。

在顺序测试方法中，两个相邻的子任务彼此高度依存，因此，操作人员必须依次执行。例如，在未对测试设备进行有效设置（指示应捕获的数据）之前即启动数据捕获是毫无意义的。同样，在数据成功传输前，我们也无法对测试数据进行分析。

每一个子任务都有其自己的执行时间。在诸多情况下，子任务的执行时间在各个测试顺序中都基本一致，但可能存在一定程度的不确定性和变化（例如：在非确定性数据传输中）。顺序测试的总体测试执行时间为各子任务执行时间的总和。因此，缩短顺序测试总时长的唯一方法就是提升测试顺序中各个子任务的测试速度。一些“高成本”的子任务也许的确存在优化的空间，但在通常情况下，往往会由于技术（如CPU时钟频率）或程序（如处理或解决时间）限制，无法进一步提升执行速度。

从图2中我们可以看到：在完成当前测试子任务后，子任务1和2中使用的测试设备回归到了空闲状态，并且该状态将一直持续，直至开始执行下一测试顺序方变为可运行状态。这意味着，子任务1和2后续测试序列的时间将会决定设备的利用率；时间越短，利用率就越高。得出该结论看似非常有利，然而，在纯顺序操作中，缩短这一时间同样非常困难。

图2：测试顺序概览。

弱并行操作

顺序执行的一种替代方法就是考虑并行执行子任务，或尽可能地并行其中一部分子任务。当单个子任务需要耗费很长时间才能完成，而它又能够在一定程度上实现解耦时，弱并行操作将是一种更加有效的替代方法。所有诸如此类的对相邻任务依存度较低的“高成本”子任务可能很适合改用并行操作。

假设完成单个DUT测试需要的五个子任务测试顺序不变。执行子任务4（数据处理和分析）很可能需要耗费大量的时间，而且成本高昂。这在5G NR应用中很常见，因为其生产测试必须满足复杂而严格的3GPP规范。显然，若将子任务4与后续子任务并行执行，吞吐量将大大提高。

单独处理子任务在大多数情况下都是可操作的。譬如，测试准备、激励生成和测试数据捕获都与数据分析结果无关，因此，对于用于这三项子任务的设备，完全可以在它们完成各自任务后直接再次启用。操作人员可以根据处理单元的并行能力，将此流程设置为允许高成本的子任务完全解耦，从而得以更快地参与到其他任务的执行当中。

在此流程中，仅部分子任务有条件获得并行执行，因此，我们可以称之为弱并行（或不完全并行）执行。如图3所示，子任务2（捕获）必须等子任务1（准备）完成后方可进行。而子任务2完成后，子任务3（数据传输）便可执行，同时，子任务1也可以即刻参与到下一测试迭代当中。与顺序执行相比，这种执行方法中测试设备可以即刻重新用于下一测试，测试设备的空闲时间间隔被降到最低，甚至不复存在。

图3：弱并行测试执行。

强并行操作

在上一示例中，性能受两方面因素的影响：可用于并行处理单元的数量以及子任务1和2的执行速度。如今，提升额外的并行处理能力通过简单的技术改造或升级就能达到，加速捕获执行则非常困难，除非捕获过程也可以并行操作。解决这一难题的办法通常就是在设置中增加更多的捕获设备。我们称这种测试执行为强并行（或完全并行）操作，只有在子任务高度解耦时才能够进行。

如图4所示，假设所有条件都处于理想情况。总共有4台可独立交付捕获数据的设备，有8台可并行执行的操作单元用以分析测试数据。

图4：具备解耦子任务的强并行操作。箭头表示任意选择的用于处理传入捕获数据的处理单元。

在此情境中，任意一个在给定时间内“空闲”的处理单元都能够从任意设备处获取可用数据并对其进行处理。下一个可用的单元亦是如此运作，于是，便形成了异步操作。此外，每台设备的捕获时长不尽相同，因此可能会导致提供的捕获数据存在缓慢或延迟的情况。但由于处理单元对于“数据由哪台设备在何时提供”并无特定要求，它们只负责处理所有可捕获的数据而无需考虑其来源，因此，捕获数据缓慢或延迟对整体性能并不会产生明显的影响。

异步操作很难以图形的方式展示，图5给出了一个定性类似的图例，前文中所提到的处理单元被分配至各个设备的“捕获流”；通过所执行的测试迭代数不难看出，与前两种情况相比，吞吐量已经有了明显提升。但是，这种操作不能保证来自特定设备的捕获数据由特定的处理单元进行处理。

图5：带有“排序”操作符的强并行操作。

需要说明的是，并行数据交付并非适用于所有情形。对单个DUT进行测试时，很可能会由于射频连接或仪表的复杂性，无法添加多个捕获设备（例如频谱分析仪）。

试验结果

为了验证并行测试执行的优势，我们设置了一个在5G应用中经常出现的现实场景，并在多个测试配置中执行了该测试。设置包含两种模式：顺序操作和弱并行操作。具体的测试系统由以下部分组成：信号发生器(R&S SMBV100B)、频谱分析仪(R&S FSVA3000)、以及一个能够并行处理16个数据集的处理平台，即R&S基于服务器的测试(SBT)单元。我们对SBT进行了配置，确保每次迭代测试中都会对EVM、ACLR以及SEM指标进行计算。发生器设置保障激励输出功率能够以59个不同功率进行输出。分析仪的设置确保设备能够以I/Q数据文件的形式捕获和传输数据。参与工作的设备通过本地千兆以太网连接，设备之间不通过任何特殊的硬件相连。为了确保结果的有效性，我们比对了所有计算的结果。

图6展示了两种场景的定性结果。它证明了顺序操作（图6右侧）的性能的确会受到单个测试步骤执行时间的限制。右下角的图放大显示了前几个测试步骤的执行情况，清晰地展示了顺序（平缓走势）和并行（陡峭走势）方法之间的差异。执行所有测试步骤所需的时间基本一致，因此，没有必要将各个步骤细分为单个子任务。所有59个步骤的测试时间总和即为单个测试的执行时间。

图6：顺序（右）和弱并行（左）测试执行对比。右下角显示前几个步骤的情形。

图6的左半部分显示了使用单个分析仪作为唯一捕获数据源情况下进行的弱并行操作。图6右下角放大的部分显示了并行测试的前10次迭代和顺序测试的前8次迭代。图中清晰展示了每个测试步骤被细分为多个子任务时的执行情况。互相重叠的红色指示条反映了分析任务的并行执行情况。从图中可以看到，单设备操作中，测试准备和数据捕获子任务对系统性能起着决定性的作用。当然，这一结果的必要条件是具备足够快速的数据传输能力以及足够数量的并行处理单元。

图6中的垂直虚线直观显示了两种场景在总测试执行时间上的差异，我们可以从中清楚地看到，第二种场景中的设备性能提升显著，而弱并行设置的执行速度比顺序测试快了将近六倍。对于任何需要加速重复测试执行的场景来说，这无疑说明取得了显著改进。在设备利用率方面，弱并行测试过程中设备的利用率几乎达到了100%。而对于完整的测试顺序，在顺序执行中，这一比率平均不足10%。

图7所示为系统性能概览。在此，系统特意配置了少量并行处理单元，用于运行相同的测试。测试人员按照每个测试步骤的各个阶段，对系统吞吐量性能数据进行记录。第一阶段（绿色）为执行输入电平的分析仪准备时间；第二阶段（橙色）为数据捕获以及传输至集中缓冲区所需的时间。第三阶段（蓝色）为用作缓冲区的文件服务器。第四阶段为数据传输至处理单元，而第五阶段（红色）则是捕获数据的实际处理。

图7：吞吐量子任务细分以及各子任务对整个系统性能的影响。

从图7中可以看出，其中有三个部分会对性能产生影响。

第一个部分：图7中的绿色斜线1，表示数据交付的速度。就这一部分而言，我们可以通过加速数据交付以及在可能的情况下实行数据源并行来改善系统速度。该部分对于系统速度的提升影响明显，然而受限于测试设置以及物理限制，以上操作并不容易执行。

第二部分：斜线1和斜线2之间的区域，它显示了由于缺乏并行处理能力，系统的等待（或缓冲）时间。当系统具备足够可用的处理单元进行处置时，蓝色区域将达到最小。如果基础平台能够支持这种可扩展性，那么该部分将是对系统整体性能贡献最大，同时也是最容易调优的部分。在这一测试用例中，我们特意将SBT设置为支持在单个硬件单元（如服务器）或跨多个单元运行的任意数量的处理单元。

第三部分：斜线2和斜线3之间的红色区域，表示单个处理单元执行分析任务的速度。优化单个单元的处理时间对于整个系统性能的影响相对较小，因此，通常它被认为是一个成本较高的调优因素。

在其他测试中，我们通过对任意数量的捕获设备进行模拟近似完成了强并行操作，其带来有效结果，即测试中的捕获数据几乎即刻可用。我们可以将后一用例当作一种设置，以用作评估处理平台的最佳性能。在有足够数据捕获设备可用的实际情况中，可以将这一用例的结果当作最佳效果的临界值。图8为强并行测试模拟与其他两种场景的对比。

图8：强并行测试、弱并行测试与顺序测试的性能对比。

结论和展望

与预期一致，强并行测试具有最佳的性能表现。由于系统配置了16个并行的处理单元，数据几乎可即时用于处理，所以才有了蓝色部分所显示的缓冲发生区域。通过增加更多的处理单元，整体吞吐时间将进一步降至最小，从而能够有效获得比顺序测试多出10个以上的改善因子。

值得注意的是图7和图8（橙色）中的数据传输部分，尽管在执行所需时长上略有差别，但该部分对系统性能的影响很小。这是使用非确定性传输协议（以太网协议的上层协议TCP）时会出现的典型观察结果，然而，异步非阻塞操作能够支持这种执行模式。

使用通常用于可扩展IT系统的系统组件，我们得以将异步操作付诸实践。借助于近来兴起的基于云的共有和本地系统，可以在超出原本用例的系统设计中使用这种构建模块。在此，所测试的SBT解决方案正是围绕这种可扩展的组件构建的，并且，它是纯本地化部署，对于外部连接没有任何要求。

这种以提高吞吐量为重点的解决方案具备多方面的优势：除了上文中讨论的可以加快整体的测试速度和吞吐量外，并行操作还能够提高设备利用率，实现更高的投资回报。最后，在降低高价值设备前期投资的需求日益增加的情况下，新的基于使用的商业模式将愈发具有市场吸引力。