基于WCET分析的实时系统轨迹获取技术Word文档格式.docx
《基于WCET分析的实时系统轨迹获取技术Word文档格式.docx》由会员分享，可在线阅读，更多相关《基于WCET分析的实时系统轨迹获取技术Word文档格式.docx（18页珍藏版）》请在冰豆网上搜索。
WCET分析；
监控方式
中图法分类号:
TP301 文献标识码:
A
实时系统目前越来越多地应用于人们生活的各个方面，特别是在航空航天、医疗监控、军事指挥和武器装备控制中。
在这些领域内，对实时系统的安全性和实时性要求是非常严格的，一旦软件控制出现问题，其后果可能不堪设想，轻则造成经济损失，重则需付出生命代价。
为此，这类软件在正式投入使用之前，必须经过彻底地测试，对其正确性加以保证，其中不可避免地要涉及对实时系统轨迹的获取及对轨迹正确性的验证，即测试预言（testoracle）。
测试预言的输入即实时系统的轨迹，为了获取此轨迹，要么在系统外部进行监测，要么在系统内部插入断言并输出。
两种方法各有利弊，外部监测不会打扰系统运行但可观测的内容受限，而断言的插入则会打扰实时系统的实际运行，进而可能改变系统的时间特性。
在测试预言的相关研究中，主要精力放在如何从实时规约自动生成可运行的预言，而对于获取实时系统轨迹则甚少讨论。
本文提出一种折衷的方法，根据规约的内容选择获取轨迹的方法，并使用最差情况执行时间（WCET）分析技术，对插桩后的系统是否能够在一定时间容忍度下正常运行进行计算分析，并对由于断言的插入而导致对系统时间的影响提出补偿方法。
本文的内容如下，第1节对测试预言与WCET分析技术进行简介，第2节提出基于规约内容和系统特性的轨迹获取方法，第3节利用WCET技术计算插桩断言对实时系统带来的打扰，并提出相应地补偿措施，最后在第4节介绍相关工作及结论。
1测试预言与WECT分析技术
1.1测试预言
测试预言是一种检验待测系统在特定执行下是否正确运行的方法[1]，由两部分构成：
一是预言信息，它描述程序行为是否正确的判据；
二是监控过程，它根据相应的预言信息来检验程序实际执行结果的正确性。
实时系统通常具有复杂的反应式和实时特性，它们通常会涉及到非常复杂的事件时序关系和比较精确的时间约束，需要自动化方法和工具的支持，在确保测试结果正确性的同时提高测试效率。
实时系统的轨迹提取是测试预言得以顺利运行的重要前提。
1.2WCET分析
为了保证实时系统中每个任务都能在其时限范围内完成，有必要分析每个任务在最差情况下的执行时间（Worst-CaseExecutionTime，WCET）。
WCET分析是实时系统的一个重要研究领域[2]，它计算给定应用程序代码片断的处理器执行时间的上限。
WCET分析保证分析的安全性（safety）和精确性（tightness），安全性指不能低估最差执行时间，精确性指必须提供可接受的高估值。
面向C源程序的WCET分析过程如图1所示。
词法和语法分析程序根据C语言的语法将C源程序翻译为内部表示的中间代码，这些中间代码包含了程序的结构信息。
程序流分析程序根据程序结构信息获得针对WCET分析的程序流信息，其中包括函数的调用关系、递归调用是否存在、循环的界限、不同if语句之间的依赖关系、if语句的分支是否包括循环终止语句（break、return），等等。
Fig.1TheWCETanalysisprocessforCsourcecode
图1 基于C源程序的WCET分析过程
C语言编译器将C源程序翻译成目标代码并获得从源程序到目标代码的映射信息，低层分析程序利用这些信息以及依赖于机器的信息和程序流信息，给出每一条指令或者基本块[3]的时间行为，其中，依赖于机器的信息包括各类指令的时间特征以及系统的配置信息。
根据程序流信息和基本块的时间特征，时间分析程序即可计算出指定程序代码段的处理器执行时间上限，即所需的任务或者程序代码段的WCET预测值。
2实时系统的轨迹获取
测试预言主要用于监控（Monitoring）待测系统的任务执行，判断其是否满足某些约束条件。
F.Jahanian[4]曾经将监控方式分为同步和异步两种。
同步监控即程序员在待测系统的特定位置显式地插入某些语法成份，通过直接操作及相关任务共享的事件历史来判断待测系统行为是否满足约束条件，测试预言的运行与待测系统的运行是同步进行的，如图2所示。
这种方式虽然无需考虑获取系统运行状态后的通信开销问题，但是，由于测试预言的运算通常计算量相对较大，因此，测试预言本身的运行会对待测系统的运行环境产生较大影响，从而会大大影响待测系统的实际运行结果。
Fig.2Synchronousmonitoring
图2 同步监控方式
异步监控方式则将获取待测系统产生的事件与对事件是否满足约束的判断相分离，各自异步执行，互不干扰，对待测系统运行序列是否与约束相冲突单独进行检测并进行相应处理，如图3所示。
这种方式对于实时系统测试而言显然是比较适合的方式，也是本文所主要考虑的监控方式，监控程序可分为两部分，一部分为监控客户方，放入待测实时系统，作为实时系统的一个任务参与调度，另一部分为监控软件，在被测实时系统之外独立运行。
Fig.3Asynchronousmonitoring
图3 异步监控方式
此外，监控还可分为外部监控与断言监控两种。
外部监控通常采用硬件监控[5,6]，通过探听和匹配目标系统的总线信号检测事件的出现。
硬件监视对于待测的实时系统不会产生任何打扰，但难以监控到系统所有状态变化，特别当系统约束中出现外部不可见的状态时，外部监控通常是无能为力的。
相对于外部监控而言，断言监控则在待测系统的源程序内通过插入断言而获取系统的相关事件和状态，这种方式当然能够获取系统任何相关的状态和事件，但是由于时间可预测性是实时系统的基本要求之一，因此，在使用断言监控方式获取系统状态时，必须量化由于断言插入而对实时系统引起的时间干扰。
基于上述各种监控方式的特点，本文提出基于规约内容和系统特性的轨迹获取方法。
2.1基于规约内容和系统特性的轨迹获取
所谓基于规约内容和系统特性的轨迹获取方法，是指根据规约中所涉及的事件类型，即是外部事件还是内部状态，以及系统事件和状态变迁特性，即是突发性还是周期性，来决定获取系统轨迹的方式。
我们采用异步监控方式，将监控程序置于待测实时系统外部。
若规约中仅涉及到系统的外部事件，则采取外部监控方式，若规约中既涉及到外部事件，又涉及到内部状态，此时我们采取混合获取方式，如图4所示，仅在系统内部状态可能发生改变的代码后插入断言，若断言发现系统内部状态发生了改变，则输出该内部状态值及状态发生改变的时间，而对于规约中涉及到的外部状态，则仍采用外部监控方式，以高速轮询获取外部事件发生的时间。
在这种方式下，监控程序的客户方所花费的CPU时间会很少，进而能够使实时系统的原调度策略，在包括该客户方程序的前提下，仍然能够完成插入断言后的实时任务的调度。
而监控程序对实时系统运行是否满足规约的判断处理功能[7]则放在独立的外部监控软件中。
这种混合获取方式，一方面能够获取规约所需的所有系统事件和状态，另一方面又能够尽可能地减小由于断言的插入而导致对系统时间的影响，同时具备了外部监控和断言监控两者的优点。
Fig.4Mixedmonitoring
图4 混合监控方式
此外，插入断言后对实时系统的影响必须加以分析。
断言在系统状态可能发生改变的部分被插入，当系统状态发生改变时，断言向系统外部的监控程序发送当前状态值及状态发生改变的时间。
在这里，断言向外部监控程序的通信开销是对实时系统的时间行为有较大影响的主要因素之一。
如果断言的每次执行都要和外部设备发生通信，那么与外部设备的每次通信皆会导致一个或者多个相应设备服务程序（比如设备驱动程序）的运行，而这些服务程序往往处于很高的优先级（如在VMS操作系统中，设备驱动程序处于核心的设备优先级中，设备优先级比应用级的所有任务的优先级都高），并且这些服务程序的执行时机往往发生在数据传输前后，因而经常会打断实时应用任务的执行。
当把这些服务程序当作任务进行调度时，会使调度策略变得非常复杂。
不仅如此，由于WCET是按照不被中断估算出来的，因此，对于具有类似高速缓存这样具有全局特性的处理器而言，通信的大量存在还将使所有应用任务的执行时间难以确定。
为此，我们进一步提出一种折衷方法，即根据系统特性决定获取系统轨迹方式。
实时系统的运行应当是时间可预测的，因此，设计人员对于系统运行特性应当比较清楚。
基于这种认识，我们在进行测试时，可以根据系统运行的特性选择监控客户方与监控软件之间的通信方式。
由于中断对实时系统的打扰较大，我们应当尽可能地减少断言引起的通信中断，为此，我们提出批处理式的通信。
如果实时系统的状态变迁具有突发性和集中性，也即经常在极短时间内出现状态变迁尖峰，那么对通信的批处理则主要考虑使用定量发送方式，即监控客户方对要发送至监控软件内部状态进行排队，当状态变迁达到一定数目时才向监控软件发送。
如果实时系统的状态变迁具有周期性和均匀性，也即状态变迁的频率趋于一定，则考虑使用定时发送方式，由监控客户方定时地向监控软件发送内部状态变迁信息。
批量发送状态变迁信息的优势在于充分利用实时系统的运行特性，尽量减少监控客户方发送中断的次数，并且可以通过适当调整监控客户方发送中断的优先级来减小对实时系统实际运行的影响。
当然，由于内部状态的获取采用了批处理的发送方式，因而监控软件在收到批量状态变迁信息后，应当有一个与外部事件发生信息按时间顺序重新组合的过程，在此我们不再详细讨论。
2.2基于规约内容和系统特性的轨迹获取方式对实时系统时间行为的影响
断言的插入将会对实时系统的实际运行产生影响，因此，实时系统在设计和编码时，应当为测试留出一定的时间余量，以支持实时测试。
假定监控客户方对应于两个任务：
发送开始和发送完成，并且假定这两个任务对其它实时任务的实时性没有影响，此时，原实时系统应当为测试预留的时间余量为：
（1）
其中，Tasks为实时系统的任务集合，WCET（TestClient）为监控客户任务的WCET，
和
分别为第i个任务被插装之后和之前的WCET。
除了系统预留时间余量外，断言对原实时系统的插装有可能引起实时系统的时序行为发生改变，例如，规约要求事件B在事件A发生后的1个单位时间内发生，即（A
[0,1]B），若原实时系统的某次运行中，事件A发生在时刻10，事件B发生在时刻11，此时系统满足规约。
但是，为了测试事件的顺序，分别在事件A、B之后插入断言DA和DB，再次运行实时系统时，事件A发生在时刻13，事件B发生在时刻15，此时系统不再满足规约。
为了保证获取的实时系统的时序行为不会因断言的插入而受到影响，需要将断言引入的时间偏移消除，从而消除断言对原实时任务的影响。
插入断言对原实时任务的影响包括两个方面，一是插入断言本身的执行时间影响了原实时任务的指令执行时刻，一是断言的插入和执行影响了原实时任务的指令执行时间，例如，改变了原实时任务的指令地址或者断言的执行指令与原实时任务的指令地址发出冲突从而改变了缓存行为，等等。
我们将在下一节描述插入断言的WCET分析及原实时任务指令执行时刻的改变值，并在第4节讨论相应的时间补偿方法。
3插装断言的时间分析和补偿
由于断言的存在，必然会对原实时系统的任务执行产生影响，而这种影响可能会导致系统行为由单独运行时的正确时序变得不再正确，即会使实时系统的事件发生和状态变化时间产生偏移。
为了消除这种偏移，需要使用WCET分析技术对插装后的断言执行时间及插入断言对原系统的时间影响进行分析。
3.1插装断言对被测系统的时间影响分析
插入点CS是程序中需插入断言的一个位置。
断言的构成是一段程序，在插入时将其作为一个完整单位插入，因此，插入点一定位于一个语句之后，另一个语句（或者是函数末尾）之前。
不妨假定插入断言为DS，原程序语句为S1;
S2，插入点位于语句S1之后，则插装后的语句序列为S1;
DS;
S2。
检测点JS是程序中的一个位置，在此位置度量插入断言对原程序语句的时间影响。
检测点JS不可能位于插入断言之中，它通常位于插入断言之后的原程序的某个位置。
假定程序的开始位置为KS（开始位置不一定是任务的第一个语句[8]），插装之前的语句序列为S1;
S2，插装后的语句序列为S1;
S2，我们通常定义检测点JS在语句S2之前。
对于任一检测点JS，断言插装之后引起的时间变化量为：
TimeChanged（JS）=TimeInstr（KSJS）TimeUninstr（KSJS）
（2）
其中，KSJS表示从KS到JS的程序运行路径，TimeInstr（KSJS）和TimeUninstr（KSJS）分别为插装之后和插装之前从KS到JS的程序路径时间。
由于插装后程序语句由原程序语句和插装语句组成，因此有：
TimeChanged（JS）=DSTime（JS）+ChangedUninstr（JS）（3）
其中，
（4）
（5）
分别表示插装语句所花费的时间和原程序语句插装之后引起的时间变化量。
DSSet表示插装语句的集合。
从公式（3）可知，插装之后该点时间变化TimeChanged（JS）包括两个部分，一个是插装语句所花费的时间DSTime（JS），一个是原程序语句插装之后引起的时间变化量，后者与前者有关。
同理，TimeChanged（JS）的计算精度也由这两个部分的计算精度决定。
对于简单的CISC处理器，两条指令的执行时间等于每条指令执行时间的简单累加，插入断言对原程序语句的执行时间没有影响，因此有ChangedUninstr（JS）=0。
但对于现代处理器则不然。
Engblom[9]把现代处理器特征对时间特性的影响分为全局和局部两类，比如高速缓存和分支预测是全局的，而流水线是局部的。
插入断言对原程序语句时间行为的影响既包括局部特征也包括全局特征。
例如，对于插装后的语句序列S1;
S2，由于DS的插入，可能使得S2所使用的流水信息发生变化[10]，从而使得S2的执行时间发生改变。
同样是由于DS的插入，有可能使得S2对应的内层地址发生改变，从而有可能使S1和S2的缓存特征发生改变，进而改变S1和S2的时间行为。
这里主要分析插入断言的时间行为。
因此假定对于检测点JS，TimeChanged（JS）总能够精确计算。
需要说明的是，由于我们这里有监控程序，能够精确获取程序的执行轨迹，所以对于简单的CISC处理器，或者一般的具有流水线和高速缓存的现代处理器，能够精确地计算TimeChanged（JS）。
3.2插装断言的构造
在对实时系统源程序进行断言插装时，我们需要在所有实时规约所关心的内部状态可能发生变化的语句之后插入断言，并且为了判断状态是否发生变化，需要在相关状态初始化阶段获取状态初值，为此，断言的结构在这两种情况下可分为四种类型。
四种类型包括初始化断言、条件断言、全称断言和存在断言，如表1所示。
Table1Fourtypesofassertion
表1插入断言的四种类型
Conditional
Forall
Exist
Initial
Meaning
forjudgingthechangeofstate
fortheformulascontainsmorethanonevariable
Others
StatementStructure
if（E）{St1;
…;
Stn};
for（i）{if（E）{St1;
Stj;
break;
}So1;
Som}
S1;
S2;
Sn
Examples
Fig.5
Fig.7
Fig.8
Fig.6,Fig.9,Fig.10
在图5～10中，EventValue为某变量的当前值，OldValue为该变量的前次值，t为该变量发生变化的时间。
Send（）将该变量的当前值与值发生变化的时间发送给监控客户方。
举例来说，规约□[0,100]（i1..20（A[i]!
=Emergency））的意思是在100单位时间内，数组A的任意分量皆不能处于Emergency状态。
而规约□[0,100]（i1..20（A[i]==Emergency））的意思则是在100单位时间内，存在数组A的某分量处于Emergency状态。
在图7中，EventValue[i]表示命题A[i]!
=Emergency的真值，图8中，EventValue[i]表示命题A[i]==Emergency的真值，而EventValue则表示i1..20（A[i]!
=Emergency）和i1..20（A[i]==Emergency）的真值。
3.3插装断言的时间计算
由表1可知，插装断言有三种形态，我们可以按照这三种形式讨论相应的时间计算：
1.顺序语句序列S1;
对于简单的CISC处理器，其执行时间为
Time（S1;
Sn）=Time（S1）+Time（S2）+…+Time（Sn）（6）
对于流水线处理器，其执行时间的计算通常使用保留表[12]，即n条指令S1;
Sn的执行时间为从S1到Sn的保留表串联之后，从第一条指令第一个阶段到最后一条指令的最后一个阶段之间的周期（cycle）数。
当具有高速缓存时，对于缓存丢失（miss）的情况，需要把丢失的时间补上。
当既有流水线又有高速缓存时，也可以有更精确的计算[11]。
2.条件语句if（E）thenS1;
elseS2;
条件语句相当于不同条件下的顺序语句，即
Time（if（E）thenS1;
）:
=
（7）
这里E为条件表达式代码，Time（E;
S1;
）为执行条件表达式之后紧接着执行语句S1的执行时间，Time（E;
S2;
）类似。
3.循环for（i）{if（E）{St1;
假定循环迭代次数为n>
0，则有
Time（for（i）{if（E）{St1;
Som}）
（8）
从上述公式能够看出，公式（7）的计算要求能够确定条件表达式E的计值结果，而公式（8）的计算不仅要求条件表达式E的计值结果，还要求能够确定循环的迭代次数。
这些信息通常是能够获得的，比如通过对断言插入适当标识，监控程序就能够确定相应的执行轨迹，从而确定插装断言的执行路径。
3.4目标系统的时间计算和修正
对于检测点JS，断言插装之后引起的时间变化量TimeChanged（JS）不仅与插入的断言有关，还与目标系统的原程序本身有关。
前面我们假定TimeChanged（JS）总能够精确计算。
要精确计算程序的执行时间，首先需要考虑程序的循环。
这里仅讨论对循环的处理，对其它语法成分的处理，可以参考文献[11,12,13]。
与通常对循环迭代次数的估算[14,15]不同，由于有监控程序的存在，并且TimeChanged（JS）的计算不要求在事先获得，因此，通过诸如在循环中插入标识之类的方法，监控程序能够及时获知循环的迭代次数。
下面假定已知循环的处于第i>
0次迭代，这里Time（KSJS）表示TimeInstr（KSJS）和TimeUninstr（KSJS）。
注意到KS位于循环的最外层。
当JS和KS位于同一个循环层次时，很显然，Time（KSJS）=Time（PKSJS），PKSJS为从KS到JS的程序语句序列。
假定JS位于比KS更深一个循环层次，即JS位于循环for（E）S之中，则有
Timei（KSJS）=Time（PKSWKS）+（i1）Time（E;
S）+Time（E;
PWKSJS） （9）
其中，WKS为语句S的开始位置,PKSWKS为从KS到WKS的程序语句序列，PWKSJS为从WKS到JS的程序语句序列。
监控程序能够根据断言中的分支判断取值和循环的迭代次数，利用WCET分析技术，根据公式（6）（7）（8）能够确定Time（PKSWKS）、Time（E;
S）和Time（E;
PWKSJS）。
从公式（9）我们还可以得到：
Timei（KSJS）=Timei1（KSJS）+Time（E;
PWKSJS） （10）
可以用同样的方法处理其它形式的循环和多重循环。
断言的插入使得事件的发生时间发生了改变，从而使得事件之间的实时关系有可能发生改变。
通过上述的时间计算，我们可以对断言的观测时间进行修正，使用修正时间可以减少或者消除插入断言对实时关系的影响。
假定监控程序对断言Ａ的观测时间为ＴＡ，修正后的时间ＴＡ’为：
ＴＡ’=ＴＡTimeChanged（JS）（11）
4相关工作及结论
传统的硬件监控方法使用特殊的硬件（如指定的处理器）通过对待测系统总线的侦听和匹配来获取事件的发生。
这些方法对系统的监控是非入侵的，但无法监控到所有事件。
P.S.Dodd、J.Joyce和H.Tokuda等人提出的软件监控方法[16,17]在软件内部插入软探针来获取事件，尽管这些方法可以获得系统的所有事件，但软件探针为待测系统所带来的影响却没有深入讨论。
F.J
升级会员 