TinyOS论文09：Random Testing of Interrupt-Driven Software

中断驱动程序的随机测试

1. 中断驱动嵌入式程序的执行路径很大，很难做到完全测试，论文提出了中断驱动的随机测试：通过随机地触发中断处理程序来实现随机测试；
2. 随机生成中断调度序列过程中，也有可能会生成违反程序语义的中断(称之为unexpected interrupt，简单来说unexpected interrupt指的就是程序本来不需要这个中，但是这个中断还是使能了，触发了相应的中断处理程序执行)，这就可能会导致随机测试结果产生误报。
3. 论文提出了RID（a restricted interrupt discipline，在TinyOS中实现了）：实现中断驱动程序的随机测试 + 避免unexpected interrupt 的误报。
4. 随机测试的实现是：程序中有与中断相关联的pending位(要有相应的中断)和enable位(pending位 + cpu的enable位)
5. RID避免unexpected interrupt的方法就是使用人工的方式将不相关的中断位(pending + enable)失能。

Abstract

1. 中断驱动嵌入式程序由于大范围的执行路径，很难做到完全测试，论文提出了随机中断测试：在随机次数中出发随机的中断处理器；
2. 本地的对中断驱动软件的随机测试应用程序：一些随机生成的中断违反了系统语义，造成错误伪报。
3. 论文贡献：RID的设计、实现、实验评估。RID：限制中断训练的测试方式来处理嵌入式软件，并且会考虑到非预期的中断。总之：执行随机测试 + 不会产生误报。

一、Introduction

1. 中断产生的问题：细粒度 + 数据竞争 + 可执行的状态空间大 + 特定场景才会被触发；
2. 随机测试的一般步骤：
   1、首先中断调度序列(指定次数的中断触发序列)的生成；
   2、然后根据中断调度执行相应的程序，并检测错误。
3. 论文采用了纯净的随机测试 + 直接的随机测试，这两种随机测试都使用了一种通用的随机算法进化地获得期望的调度。
4. 论文的实验：最坏的栈深度，之前的方法不好的原因：很多路径没执行到，包括明显的嵌套 + 之前的随机中断调度会有反常的中断(程序不能正确处理导致误报)
5. RID解决了反常中断问题：
   1、RID使用了已存在的支持硬件支持中断掩码为来处理程序。实现方式为：部分自动程序转化，该步骤需要手动修改源码(中断向量)；
   2、RID的另一个优点：不允许重新进入旧的中断驱动 + 避免误报。

Interrupt and Interrupt software

1、中断驱动软件
应用程序和中断相分离；
2、中断的处理

1. 每一个中断都有一个与之相关联的pending位，当中断触发条件满足的时候这些位会形成一个集合。
2. 每一个中断也有一个与之相关联的enable位；(pending为满足 + CPU的enable位满足)
3. 1 + 2 满足则执行中断处理程序；

3、抢占、嵌套。重入

1. 中断执行模式与线程的两大不同点：
   1、中断不能阻塞：除非发生抢占，否则会执行完毕；
   2、中断可以抢占非中断活动，反之不行。
   中断之间是否会发生抢占取决于嵌入式系统操作的中断掩码；

2. 中断嵌套：中断之间发生抢占；

3. 重入中断：一个中断本身直接或间接发生抢断；重入中断是同一时间的多次调用：会造成enable位不能及时处理(总之重入中断很容易发生错误，应避免)

3、特定中断 VS 自发中断
(中断可以大致分为以上两类)
4. 自发中断：由外部设备随时都能发出信号；
5. 特定中断：响应特定中断处理器的特定中断

四、反常中断

1. 反常中断：即中断不能在任意时间到来。例如，对于请求中断，没有请求但是中断还是到达说明该中断为反常中断(??)

5、中断调度控件

1. 中断调度可以被看成是高维空间的占据点。
   1、首先找出中断调度；
   2、通过测试到可达状态

3、A Restricted interrupt discipline

1. 解决反常中断问题的困难点：
   1、哪一个状态下会有哪些中断没有说明，只能从源码中查看。
   2、程序中的归并点只能假设有某一个特定的中断。
2. 论文使用RID的方法来解决：通过软件的方式忽略反常中断，当他们不在反常时即将执行。
3. RID的实现思想：使用系统基于硬件中断使能位的运行代码来避免每一个中断向量一直处于serviced状态，在这个状态中系统不用处理这些中断。实现方式很直接：第一步是人工 + 第二部是自动化；
4. RID的实现步骤：
   1、首先，开发人员手动确保设备初始化代码使得请求中断失能；对于自发中断，系统只要一有能力处理自发中断，自发中断就能使能（即相应的子系统完全被初始化了）。
   2、请求中断应该失能除了有请求，并且处理器开始执行；自发终端失能只有在处理器正在执行的时候。这一步骤可以自动化实现：对于请求中断进行注解 + 使用定制的扩展CIL用执行特定中断掩码操作的代码来替代注解。

Implementing RID in TinyOS

1、TinyOS and NesC
2、修改TinyOS

1. 论文涉及到TinyOS应用程序的五种中断：时钟、ADC、串口号传输和接收中断、SPI中断。五种中断的RID都实现了：只需要修改TinyOS底层设备驱动文件。
2. 例如ADC中断：首先修改源码让ADC初始化之后中断处于使能状态；然后samplePort函数实现注解的转化；最后使用CIL处理序言和后记。

实验和评估

1、Avrora
Avrora适用于中断调度，读取相应的中断调度然后生成相应的模拟事件；

2、中断调度的生成

1. 中断调度的生成即中断请求列表的生成。中断请求：中断向量 + 触发事件。中断调度生成器一中断向量为输入(随机的中断调度 + 每一个调度向量都有一个密度)
2. 中断密度： 太少，中断抢占不会经常发生；太多，抢占太频繁。经验值：系统处理中断周期的50%。

3、测试方法
1. 程序运行不出错即为正确程序(要么Avrora发现错误、要么)：
1、Avrora能够检测非法访问内存 + 非法的指令执行；
2、串口 + 输入的广播包；

4、案例分析1

1. TinyOS示波器应用程序；

5、案例分析2：近似最坏情况的栈深度

1. 使TinyOS应用程序到一个最坏的栈深度，有利于防止栈内存溢出的情况。
2. 问题：静态分析精确度高，但实际的代码执行会导致大的栈深度。

6、案例分析3：找出错误假设

1. 利用案例2的结果找出了一个最坏深度时程序所占的内存，来检测程序，如果程序所占的内存大于坏深度时程序所占的内存，则说有有数组越界的情况。

6、Related work

1. 论文实现了中断驱动软件的随机测试，并且解决了随机中断调度中反常中断的问题。
2. 之前类似的工作有：利用遗传算法找出嵌入式程序进入最坏深度的中断调度。

7、Future work

8、Conclusion

1. 论文提出了RID：针对反常中断的限制性中断规则，来对中断驱动的随机测试。