箭载飞控软件系统最差情况执行时间测试研究

姚佳瑜

摘要：为了更加准确地完成嵌入式箭载计算机飞行控制软件系统最差情况执行时间的自动化测试工作，根据软件的高实时性特点，结合静态分析和动态测量的优点，提出了基于RapiTime测试工具及应用RTBx硬件的测试解决方案，构建了嵌入式箭载计算机飞行控制软件系统最差情况执行时间的测试过程，并将测试结果与其他方法进行比较，通过实验验证了所提方法的有效性，为提升软件的性能及可靠性提供依据。

关键词：嵌入式软件测试；系统最差情况执行时间；软件插桩；动态测试；基于测量的时间分析方法

中图分类号：TP302 文献标识码：A 文章编号：1009-3044（2016）07-0087-03

Investigation on the Testing of Worst-Case Execution Time of the Rocket Flight-Control Software

YAO Jia-yu

（Shanghai Aerospace Electronic Technology Institute， Shanghai 201109， China）

Abstract： To accomplish the automatic test of the system's worst-case execution time， according to the real time performance of the flight control software based on embedded system， a test solution based on RapiTime testing tool and application RTBx hardware is proposed. The test procedure of the worst-case execution time of the software system for the flight control software system is constructed. The result provides the basis for improving the performance and reliability of the software.

Key words： testing of embedded system； worst-case execution time； software plug-in； dynamic testing； the analytical method based on measured execution time

嵌入式箭载计算机飞行控制软件（以下简称飞行控制软件）作为火箭控制系统中的核心组成部分，是一个复杂的软件。由于其高实时性要求，就要求其在规定时间内（毫秒级）完成任务处理，要求系统严格按照一定的时序进行处理。这就要求对此软件中关键模块进行系统最差情况执行时间的测试。

1 飞行控制软件系统最差情况执行时间测试的需求与困难

在实时系统中，确保系统执行时间的正确性是非常重要的。实时系统执行时间的要求相对于非实时系统来说有明显的不同：非实时系统的时限是柔性灵活的，可以容忍偶然的超时错误，超时造成的后果并不严重，仅仅是轻微地降低了系统的吞吐量；而实时系统有刚性的、不可改变的时间限制，它不允许任何超出时限的错误，超时错误会带来损害甚至导致系统失败、或者导致系统不能实现它的预期目标[1]。

因此，非实时系统的时间性要求集中在平均的执行时间上，关注于系统在一段时间内的平均性能，保证系统的高吞吐量。而实时系统的时间性要求更关注于最差情况下的执行时间（WCET，worst-case execution time），要求在逻辑结果正确的前提下，在规定的时限内能够传递正确的结果，满足设计的响应时间要求。

利用普通的分析工具（如SystemVerify），程序开发人员只能得到软件的平均执行时间和测试过程中所出现的最长的执行时间信息。对于一般的非实时系统来说，这些信息对于分析系统性能已经足够了[2]。但对于具有严格时间性要求的实时系统来说，开发人员更关注于软件的最差情况执行时间（WCET）。确保软件的最差情况执行时间能够满足系统的时间性要求对于保障整个系统的可靠性具有非常重要的意义[3]。

然而随着整个计算机技术的发展，软件和处理器愈加复杂，如何得到软件的最差情况执行时间是一个非常困难的工作，这是由于：首先，软件的代码量日益增加，功能愈发复杂，因此识别软件的最差执行路径并加以测试是非常困难乃至于很难完成的事情。其次，随着一些新技术在硬件上的使用，如指令和数据cache，流水线结构和分支预测单元等，虽然这些技术极大地提升了硬件的性能，但也正由此指令不再是按照固定的时钟节拍来顺序执行，所以使得最差执行时间变得更加难以确定[4]。

目前国内的现状基本上是依赖技术人员的经验对系统执行时间进行估算，缺点在于：一是无法全面考虑各个软件模块的执行时间在真实的硬件环境中能否满足设计要求，最差执行时间的获取依赖于测试用例的设计以及测试路径的选择，往往需要经过几轮测试之后才能逐步确认；二是由于无法得到每个函数语句的精确执行时间，代码优化工作很困难，在代码执行效率和代码维护（可读性）两者之间很难找到一个平衡；三是由于手段落后，一些隐藏的时间性错误在常规的测试过程中无法显现，带来严重的设计隐患。而系统一旦在最差情况下的执行时间超出了设计的要求，就会带来严重的质量问题[5]。

2 飞行控制软件系统最差情况执行时间自动化测试工具

2.1 系统最差情况执行时间测试工具的选择

对嵌入式箭载计算机飞行控制软件系统最差情况执行时间进行自动化测试，一般使用软件插桩技术来实现，其原理是：在被测试源代码中的执行路径上插入一个桩点，通过运行桩点来进行数据信息采集，获取被测试程序的最差情况执行时间信息等。

一般通用的平台上（例如Windows），由于其平台资源丰富，性能强大，一般的插桩对其影响比较小；但是对于嵌入式软件资源相对比较匮乏，性能相对较低，就要求考虑对插桩后的软件进行影响分析，这些影响主要体现有：

1）源代码插桩后空间膨胀。嵌入式系统资源匮乏，内存空间较小，但插桩源代码会带来源码膨胀，统计比较分析得到源代码膨胀率会达到20%-40%，往往超过嵌入式系统所提供内存空间，无法下载执行[6]。

2）源代码插桩后时间膨胀。嵌入式系统对实时性要求比较强，但是由于插桩使系统增加了额外的开销，函数的执行时间增加，性能下降，人机导致软件时序混乱，功能失效[7]。

RapiTime是将动态测量和静态分析两种方法相结合的工具。测量方法的优点在于可以得到软件的真实执行时间[8]，而静态分析方法能够通过对程序进行分析而得到最差情况的执行路径。RapiTime结合了这两种方法的优点而避免了它们的缺陷。

RapiTime采用“基于测量的时间分析方法”，不仅可以计算出执行时间的最大值，还可以通过静态分析得出它们分类，从而得出不同硬件影响下执行时间的区别，并识别出缺乏效率的代码。从而不仅能够避免实时软件的执行时间问题，同时对于提高软件性能也有很大帮助。通过实验得到使用RapiTime工具插桩后飞行控制软件源程序的空间和时间膨胀率，见表1。

通过上述分析，本文提出应用RTBx硬件的解决方案，来完成嵌入式箭载计算机飞行控制软件最差情况执行时间的自动化测试。

RTBx是RapitaSystems 公司提供的一个用于目标机程序执行时间获取的可选硬件，在用户的目标机硬件资源有限的情况下，用于记录用户应用程序执行的时间信息并输入到RapiTime中进行分析。使用RTBx能够方便的完成程序执行时间的获取和存储。

RTBx提供的硬件接口能够与用户目标硬件的输出端口直接相连，当程序执行到时间获取代码时，对应的执行时间信息会输出到目标硬件的输出端口，与之相连的RTBx会记录下检测点的标识和对应的时间信息，用于RapiTime后续的分析过程。RTBx的优点在于：

1）测试不会被中断：RTBx能够对得到的测试数据采用压缩格式进行存储，这样做一方面可以提高存储的数据量，同时减低传输测试数据的时间。TraceBox的标准配置包括一个定制的I/O接口板（自带1G的内存），2G的高达1066MHz的CPU内存，以及1TB的硬盘。虽然TraceBox的配置已经足以满足现阶段最复杂的程序的分析要求，但也可以根据用户的需要进行扩展。即使是采用最高的采样频率，标准配置的 RTBx也可以无间断的持续记录数天的测试数据。

2）最大化的测量时间精确性：RTBx用于记录检测点的标识及对应的时间戳信息，检测点的开销仅仅是向某个指定的输出端口写一个常数，这通常只需要一到两条汇编语句就可完成。这种方法将检测点代码的尺寸和执行时间的开销都降到了最低。RapiTime可以通过在分析时减去一个固定的开销时间从而将检测点的时间影响进一步减少。

3）对于目标机的高适应性：由于RTBx直接与用户目标硬件的输出端口相连（可以是一个固定的输出端口或者根据目标硬件的实际情况也可以是由不同输出端口的单个输出位组合而成），因此RTBx适用于任何目标机体系结构，而不是局限于某种特定的处理器类型。

RapiTime插入的检测点具有唯一的标识（采用32位或者16位的范围）。但是，当用户目标硬件上可用的输出位数有限时，RapiTime所独有的技术保证能够采用较少的输出位数就能标识出检测点，从而适用与资源有限的目标环境。

4）快速设置和远程管理：RTBx的控制和显示并不运行在用户的目标系统上，是通过配置和运行在Windows或Linux远程主机上的GUI进行控制。

5）长时间连续跟踪数据（采用最高采样频率，存储32位/16位数据持续时间可达69小时/ 138小时）。

6）不存储于目标内存中，使用1M的缓存和6.25ms的存储速度，RTBx的采样频率至少为20M/秒；作为对比，使用逻辑分析仪，在8位的采样宽度下，使用20M/秒的采样频率，通常只能存储0.2秒的数据。

7）低检测开销：测试代码所带来的额外开销极低（通常每条测试代码的执行只需要一至两条CPU指令）。

8）对目标机的影响极小：与测试数据直接存储于目标机内存中不同，不需要预留大量内存为测试所用。

9）为收集测试数据所需的工作量很少：不需要为了获取测试数据而停止应用程序的执行；不需要为了将测试数据上传到开发主机中而建立单独的连接方式。

2.2 RapiTime测试工具技术原理与特点

RapiTime需要根据目标程序的执行时间信息来进行软件的时间性能分析。所谓的执行时间信息是由一组成对的数据组成，包括检测点的标识（ID）和对应的时间戳信息，这些数据是随着目标程序的执行而自动产生的。

通常，执行时间信息是在程序的执行过程中直接存储在目标机内存中，开发人员需要在目标机的内存中预留出存放测试数据的部分。对于每个检测点，检测点的标识和对应的时间戳信息都需要存储在内存中。当测试结束后，存储在目标机内存中的测试数据需要上传到开发主机中使用RapiTime进行进一步的分析。

RapiTime采用的“基于测量的执行时间分析方法”结合了静态和动态分析方法的优点，动态测量是通过在真实硬件平台上的“运行时测量”来实现，并结合对软件结构的静态分析，从而得到系统在具体目标硬件下真实的最差情况执行时间。RapiTime的技术特点有三点：

1）RapiTime使用测量的方法以确定代码不同分支的子路径在具体目标硬件上的真实执行时间。由于不需要对处理器进行建模，因此RapiTime能够对8、16、32位处理器及DSP等硬件提供广泛的支持。

2）RapiTime使用路径分析技术对代码的整体结构建立一个精确的数学模型，并确定代码的哪些分支可以组合形成完整可行的路径。RapiTime对于实时系统所广泛使用的C和Ada语言提供全面的支持。

3）RapiTime结合测量和路径分析信息，利用连接函数理论，捕获对于不同的处理器硬件下各个路径的执行时间，从而得到相对应的最差执行时间。

3 飞行控制软件系统最差情况执行时间测试技术

3.1 飞行控制软件系统最差情况执行时间测试过程

嵌入式箭载计算机飞行控制软件系统最差情况执行时间测试过程共需6个步骤。

1）代码预处理

通过一个自动化的程序将一些轻量级的时间检测代码加入到源程序中。

RapiTime提供cins工具自动化地将检测点添加到源代码中 （*.c文件）。在预编译阶段对源代码进行处理，将所有的宏定义和#include定义全部展开。cins 工具能够自动地将检测点添加到经过预处理的代码中（通常为*.p文件），根据测试的需要可以选择在程序中的所有分支点中都添加检测点。所谓的检测点指的是一些轻量级的代码执行时间获取代码。将添加过检测点的代码（*.i）以及检测点的执行程序（rpt.c）编译在一起生成可执行的程序，下载到目标机硬件中执行。

在编译的过程中，cins工具同时对每个插入检测点的C文件进行结构分析，生成对应文件的语法结构分析文件（*.xsc），用于后面的结构分析过程中。

2）结构分析

xstutils工具用于分析由 cins 生成的.xsc 文件中包含的结构信息。 xstutils 生成文件是待分析程序的语法结构说明。通过对经过预处理的代码进行分析，就能够得到整个程序的结构信息，并生成代码调用的语法树的总体结构说明。该说明用于后续的执行时间的跟踪运行和最差情况执行时间分析过程。

3）获得程序执行时间的数据（运行测试用例）

将经过预处理的程序在目标处理器上运行，也可以运行在周期准确的 CPU 模拟器上，目的是使得代码在各种条件下执行所有的分支路径。

在跟踪过程中，RapiTime提供两种手段用来获得程序的执行时间信息：

第一种：当某一个时间获取代码被执行时，则该获取代码的标识和相对应的时间戳信息就会被纪录下来，并存储在板上目标板上的内存中，在测试结束后可上传到RapiTime的运行环境中，用于接下来的时间性分析过程。需要注意的是，在这种方法中，由于程序的执行时间信息是存储在目标板的内存中的，因此会有一定的内存开销。

第二种方法：在目标板的内存资源有限的情况下，用户可以选择使用RapiTime的可选硬件RTBx来完成执行时间的获取和存储。

4）测试数据预处理

对上步过程中得到的时间信息文件进行处理，对数据进行过滤和更正（如定时器反转），并将数据压缩为二进制格式，与第二步中得到的程序结构说明相结合得到函数级的执行时间信息。

5）最差情况执行时间分析

一旦跟踪结果已处理，分析过程的下一步就是最差情况执行时间的计算。 将子路径的执行时间和代码的整体架构相结合，生成一组针对特定代码执行范围的执行时间文件。

6）生成测试报告

生成基于Eclipse架构的执行时间报告。

3.2 飞行控制软件系统最差情况执行时间测试结果分析

通过对嵌入式箭载计算机飞行控制软件进行插桩，使用插桩后的源码替代原始的源码，重新编译成功后，下载到目标机上运行执行测试用例，测试的执行时间分布结果见图2，其中，Max、Average、Min为通过测量的方法得到的软件在测试过程中所出现的最大、平均和最小执行时间。

从图1中可见，使用RapiTime测试工具测到的最差情况执行时间超出了使用测量的方法得到的测试结果，并且超出了软件需求规格说明中所提出的性能要求，发现了以前未能发现的问题，基于RapiTime测试工具所得到系统最差情况（WCET）和最佳情况（BCET）执行时间更接近于真实结果。测试方通过提问题单的方式建议开发方对程序进行优化，以满足性能要求。

4 结束语

本研究详细地阐述了嵌入式箭载计算机飞行控制软件系统最差情况执行时间测试的需求与难点，详细介绍了基于RapiTime测试工具及应用RTBx硬件的测试解决方案的技术原理，并通过具体的实验分析比较了测试工具插桩后的代码膨胀率，为测试工具的选择提供依据。介绍了嵌入式箭载计算机飞行控制软件系统最差情况执行时间测试的全过程，详细地分析和研究了系统最差情况执行时间测试的结果，使得软件设计师能够依据测试结果提升软件的性能和可靠性。

参考文献：

[1] 高炽扬，曹玉红.测试目的变迁带来软件发展[J].软件世界，2005（10）：87-88.

[2] 郑人杰.计算机软件测试技术[M].北京：清华大学出版社，1992：43-48.

[3] John C，Munson. Software faults，software failures and software reliability modeling[J].Information and Software Technology，1996（38）：687-699.

[4] Ian Sommerville. Software Engineering[M].北京：清华大学出版社，2004：115-117.

[5] Erman Coskun，Martha Grabowski. Software complexity and its impacts in embedded intelligent real-time systems[J].The Journal of Systems and Software，2005（78）：128-145.

[6] 乔文军，万晓冬.嵌入式软件覆盖测试工具的研究[J].计算机测量与控制，2007（9）：1238-1240.

[7] 佟伟光.软件测试[M].北京：人民邮电出版社，2008：12-24.

[8] 李书浩，齐治昌.程序设计规则检查：一种保障软件质量的基本方法[J].计算机科学，2003（11）：148-151.