控制软件多任务程序运行时错误检测方法

王正锋 李纪波

摘 要发动机控制软件多任务程序运行时，共享变量的处理容易发生数组访问越界、除零、数据溢出等错误，从而造成异常的后果。采用动态测试的方法检测此类错误成本大、效率低。本文借助PolySpace测试工具，模拟软件动态运行时的行为，使用静态验证的方法有效检测可能发生的运行时错误，更高效地发现多任务程序中的缺陷。

【关键词】多任务 运行时错误 静态测试 PolySpace

1 引言

航空发动机控制系统目前广泛采用全权限数字电子控制系统（FADEC）。其中的控制软件为高安全等级软件，采用多中断或者多任务的架构设计。在软件的设计过程中，很可能会出现多个任务或中断服务程序对共享变量进行操作的处理，对这处理的设计如果考虑不周全，很容易导致程序在运行过程中出现数组访问越界、除零、负数开方、整数或浮点数据溢出等错误，产生预定义之外的不正确结果或者处理器异常复位等后果。

常规的测试手段对于上述程序运行时错误的检测并不能起到很好的效果。使用PRQAC进行静态分析可以检查代码的编程规范、分析程序的静态结构，但是并不分析代码的动态行为。在真实环境中执行动态测试，测试用例能够覆盖的场景有限，不一定能够触发错误发生，尤其对于偶尔才出现的问题，需要大量重复测试才可能发现。除此之外，动态测试能够发现异常现象，但产生异常的原因还需要更多时间去定位，效率很低。

本文介绍了一种使用静态验证的手段检测多任务程序运行时错误的方法，借助工具软件PolySpace，模拟软件动态运行时的行为，更高效地发现软件缺陷。

2 测试原理

2.1 PolySpace的工作原理

PolySpace使用语义分析技术，它依靠大量的数学定理提供的规则去分析软件的动态行为，基于变量的数值范围和变量之间的关系、程序的控制结构、程序内部过程之间的关系（函数调用）、多任务分析等进行运行时错误的检测。

其分析结果对程序运行时可能会出现问题的代码实现，会给出橙色的告警标识以及可能引发错误的场景；对于肯定会出现问题的地方，会给出红色告警和引发错误的场景；对于不会出现问题的部分，会给出绿色的標识。由于PolySpace分析验证时计算出的变量范围始终是实际运行时变量范围的扩展集，所以分析的结果不会漏掉可能出现的错误。

根据给出的告警和场景，进一步通过人工分析和确认，最终定位问题。

2.2 多任务程序运行时错误的分析

在基本的语义分析基础上，对于多任务分析，还有一些必备的条件和假设：

（1）main函数是可结束的，即结尾的“}”必须可达；不存在无限循环或者引起红色告警的错误，这样才能保证多任务入口函数可以开始分析。

（2）任务或者是中断/线程列表，其函数原型必须为void func_name（void）的形式。

（3）main函数结束后，开始分析各任务或者入口函数，分析的时候不会限定任务或中断服务程序运行的顺序和优先级（不影响分析结果）。

（4）由于不能明确地构建任务的具体优先级，所以分析时会模拟所有可能的优先级顺序。

如果要分析的源程序不满足这些条件和假设，需要人工对程序进行修改以满足要求，以便进行分析。另外，可以通过人工编写桩函数来调用实际的任务程序，使多任务的分析更接近实际运行场景。

3 项目应用实践

在某项目发动机控制软件中，曾经出现过两个任务对共享的数据结构进行操作，其中一个任务对数据结构中的元素进行除法运算，出现除零操作而导致程序运行异常的问题。以下内容将对问题进行描述，并介绍通过Polyspace进行多任务分析检测出此问题的实践。

3.1 软件问题概述

某项目控制软件中存在多个中断处理程序，其中频率量的采集处理在两个定时任务中实现。5ms定时中断任务中读取计数值，优先级稍低的25ms任务将计数值当作除数，计算频率量。如图1所示。

软件设计之初考虑到这个FreqBuff[0]可能为0，因此在做除法之前做了极小值保护（使FreqBuff > 1000）保护，防止由于其等于0而出现除0的情况。

但是5ms定时中断优先级高于25ms中断，如果由于时序原因，如果恰好在所做的除零保护之后，25ms任务被更高优先级的5ms定时任务打断，FreqBuff[0]赋值为0，再回到25ms任务进行除以FreqBuff[0]的运算时将会出现除零的错误，软件运行出现异常。问题示意如图1所示。

此问题引发的异常表象，不是每次运行都会出现，即使出现该问题引发的异常，进行故障排查和原因定位也要耗费大量的时间和人力，同时对排故人员的能力和经验要求也比较高。

如果在开发阶段或分析审查阶段就能找出这个问题，会节约很大成本。

3.2 借助Polyspace进行分析

进行多任务程序分析的总体执行步骤为：先初始化全局变量，然后分析main函数，main函数正常结束后分析多个任务程序的运行。

Polyspace不会自动识别需要分析哪些任务，需要对原代码进行一些改造、打桩或编写驱动程序来保证分析过程可以正常结束。

首先，对main函数进行改造。原代码的main函数中存在一个无限循环，可以将循环中执行的函数拿到main函数外作为一个单独的任务进行分析。这样可以保证main函数能正常结束，且不会漏掉循环中执行的函数的分析，具体更改如图2所示。

然后手动编制桩函数，调用要分析的多个任务程序。该项目中共有两个定时器中断和串口、AD采集、DMA应答、通讯中断等多个中断服务程序，仅考虑要分析的两个定时中断任务，它们的函数原型为VOID IsrTimer1（VOID） 和VOID IsrTimer2（VOID），符合能够进行分析的条件，无需改动。自己建立一个C文件，如Poly_multitsk.c一起加入到工程中，手动编写的驱动函数如图3所示。

这样的驱动函数可以模拟每个中断服务函数被调用0次或者多次，且各任务相互之间可被打断。

最后，对分析选项进行必要的配置。除了一些通用的配置选项，在Multitasking选项中，设置好要分析的多任务的任务入口函数，这里包括我们手动编写的两个驱动函数和之前从main函数中摘出的一个循环任务。配置完成，即可在服务器端进行分析。

3.3 查看结果和人工分析

分析结束，Polyspace会产生结果文件，可以很容易查看分析后给出的各类告警。对于前面提到的程序中存在的问题，分析结果中给出了橙色的告警指示，如图4所示。

结果中会明确给出可能出现错误的代码所在的函数和文件，而且点击告警处，可显示导致错误的操作和场景，即除法运算的右侧操作数可能为0。然后进一步分析可能导致除数为0的原因，是在另一个优先级更高的中断任务中将这里作为除数的全局变量赋为0。

上述内容是对某项目程序中已知存在的问题进行实际的分析和验证，只对两个任务的交叉运行进行分析来举例说明。可根据实际情况分析更多的任务，模拟更多的任务运行模式进行分析。

4 总结

在项目开发阶段或早期的测试阶段，根据实际需要，对程序中的多任务进行分析，可以尽早的发现可能出现的运行时错误。这些自动分析产生的可能发生错误的告警，并不一定会在真实运行时发生，根据这些信息，结合实际代码对告警的内容进行更进一步的人工确认和分析，直到找出问题的根本原因，是必不可少而且至关重要的工作。

借助Polyspace进行自动分析需要的准备工作和后续的人工分析确认，需要花费一定的时间，但相对于软件使用和维护阶段再去对这些运行时错误进行排查和定位，成本是很低的，效率也大大提高，是非常有效的检测多任务程序中运行时错误的方法。

参考文献

[1]刘春裕，王蕾.基于PolySpace的嵌入式软件内存测试[J].电脑技术与技术，2010，6（01）：85-87.

[2]PolySpace Products for C Users Guide：5-19.

作者单位

中国航发控制系统研究所 江苏省无锡市 214063