RTOS测试（韩国方案）

Posted 2023-06-09 pythontesting

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了RTOS测试（韩国方案）相关的知识，希望对你有一定的参考价值。

简介

在本文中，我们重点讨论了实时操作系统的验证和测试程序。

测试的目的有两个。一个是显示经过验证的模型属性是否被继承到了代码中。另一个目的是发现代码的错误要检查结构覆盖率和功能等。

在测试所开发的操作系统软件后，我们将其与数字工厂保护系统（DPPS Digital Plant Protection System）软件一起嵌入测试板中，该软件模拟安全关键的反应堆保护功能。开发的系统应该满足10的-3方的故障概率（pfd failure on demand），以表明它对安全关键应用是足够可靠的。我们通过在测试板上进行必要数量的测试来证明这一点。

方法

方法分为三部分：

在生命周期的每个阶段进行规范和验证
为软件测试生成测试数据
进行嵌入式系统测试

2.1 软件规范和验证

我们用图形化的形式化语言来规范实时操作系统，并用模型检查来验证它。我们使用STATEMATEMAGNUM工具集，I-Logix，作为形式语言和模型检查器。STATEMATE MAGNUM是基于活动图和状态图的。
活动图用于功能描述，状态图用于系统的行为描述。状态图是一种具有数学语义的定义明确的形式语言。使用状态图，我们可以用状态和它们之间的转换来描述需求/设计阶段的行为。状态图中的过渡是五元组（源，目标，事件，行动，条件）。状态图中的箭头从源头到目标，被标记为e[c]/a，这意味着当条件c为真时，事件e触发了过渡，当过渡时，行动 "a "被执行。行动\'a\'可以是一个行动的列表。

STATEMATE有一个仿真工具来验证系统设计。利用仿真，我们不仅可以验证每个模块，还可以验证整个系统。

STATEMATE MAGNUM还提供ModelChecker作为形式验证工具。
模型检查可用于检查设计中关于特定属性的动态行为。重要的是要知道，模型检查与传统意义上的测试不同。与测试相反，模型检查在数学意义上是完整的。如果模型检查器证明了一个特定的属性在模型中得到了满足，那么结果就是100%正确的。如果模型检查器显示STATEMATE设计中的一个基本状态是不可达到的，这意味着没有人会找到仿真运行（只有输入变量在执行过程中可以改变），其中的跟踪路径包括特定的基本状态。因此，模型检查可以被称为穷举测试。所有这些设计信息都由工具自动翻译成模型检查器内核的输入语言。另一方面，用户必须定义要检查的属性。

我们可以从STATEMATE的代码生成器中得到一个自动生成的代码，预计它的错误会比人工实现的少。

2.2 软件测试

实时操作系统的测试以两种方式进行：在软件测试和嵌入式系统测试。软件测试的重点是RTOS软件本身，而嵌入式系统测试的重点是与嵌入RTOS的应用软件的集成。

在单元测试的情况下，我们通过对代码应用白盒测试标准来选择单元测试数据，这些代码是在实现阶段从STATEMATEMAGNUM自动生成的。我们还通过对设计阶段指定的Statecharts应用分支覆盖标准来选择单元测试数据。在集成测试的情况下，我们通过利用设计阶段指定的Statecharts来选择集成测试数据。在系统测试的情况下，我们通过利用需求阶段指定的活动图来选择系统测试数据。

2.3 嵌入式系统测试

作为这个测试的标准，我们设定了千分之一的故障要求，这被用作安全关键型核系统的可靠性测试标准。作为测试数据，我们生成随机的故障条件组合，直到它满足获得所需的故障数量。

参考资料

软件测试精品书籍文档下载持续更新 https://github.com/china-testing/python-testing-examples 请点赞，谢谢！
本文涉及的python测试开发库谢谢点赞！ https://github.com/china-testing/python_cn_resouce
python精品书籍下载 https://github.com/china-testing/python_cn_resouce/blob/main/python_good_books.md

形式化规范和验证程序

3.1 实时操作系统的要求

实时操作系统与一般的操作系统不同，它的逻辑正确性不仅取决于其输出的正确性，而且还取决于其输出的及时性。此外，像其他操作系统一样，必须至少提供以下三种功能：任务调度、任务分发和任务间通信。调度是决定下一个控制CPU的任务的过程。当中断发生时，它被调用，任务完成其工作，正在运行的任务被暂停。

当调度器被调用时，它扫描准备就绪状态的任务列表，根据调度策略选择任务，并将CPU控制权交给它。调度是一个切换、保存和恢复运行任务和下一个运行任务的上下文的过程。在本文中，调度员定期创建任务并使其处于准备状态。任务内通信使任务能够交换信息并相互同步。消息邮箱和消息队列被实现来执行任务间的通信。

用户代码作为一个任务被执行，有预定的执行时间和周期。操作系统可以在任何用户任务的执行过程中打断它。

3.2 实时操作系统规范和验证

实时操作系统的功能规范如图3.1所示。每个方框都包括实时操作系统的功能。线代表功能之间的通信，虚线框代表外部环境。实时操作系统包含内核、中断处理程序和任务。内核包括调度器、任务管理器、消息信箱和消息队列。任务模块有七个任务：五个任务的优先级相同，一个任务的优先级更高。最后一个被分配为空闲任务。

调度器的行为规范调度器执行基于优先级的，或者说是轮回的调度。RTOS中的嵌入式软件在其应用中有两个不同的任务。一个是监控和投票任务，另一个是行程任务。跳闸（关机）任务有最高的优先级，其他任务有相同的优先级。
图3.2显示了调度器模块内部的行为。
对于任务间的通信，我们的实时操作系统提供了消息邮箱和消息队列。

图3.3显示了任务的行为。每个任务基本上有五个状态：休眠、准备、运行、等待和ISR。休眠状态表示任务未被创建。处于休眠状态的任务可以在任务进入它的时期并花费抵消时间后被创建。处于准备状态的任务正在等待调度，而调度已经准备好运行。处于运行状态的任务在需要使用资源或花费时间时过渡到等待状态。当运行中的任务被系统打断时，将过渡到ISR状态。调度器模块被用来唤醒任务。
在规范之后，使用STATEMATE对RTOS进行仿真，如图3.4所示。

图3.4 RTOS的模拟通过ModelChecker验证的属性如下：

指定的RTOS是否有不可到达的状态。
指定的实时操作系统是否是确定性的。
两个或多个任务是否可以同时处于运行状态。

其结果如图3.5所示。

在Statecharts中的设计规范可以自动翻译成C代码，在后面的阶段进行测试。

4. 软件测试

4.1 单元测试

在RTOS的单元测试中，单元从Statecharts中提取出来，并分别自动转换为C代码。单元测试有两个目的：一个是识别自动转换的C代码是否正确，另一个是检查代码的行为是否与我们设计的一致。

4.2 基于状态的单元测试

我们通过应用分支覆盖标准，从Statecharts中指定的单元中提取基于状态的单元测试数据。分支覆盖标准需要覆盖所有的转换，之所以选择这个标准，是因为规范本身是基于状态和它们之间的转换。
为基于状态的单元测试生成测试数据的程序如下。

(1) 识别要测试的单元。
(2) 为基于状态的单元测试选择测试数据。
- 对从设计规范中提取的单元应用分支覆盖标准。
- 选择测试数据来覆盖所有的分支以满足标准。

我们使用结构测试工具ATAC（Automatic Test Analysis for C进行基于代码的测试。我们选择两个白盒测试标准：语句覆盖标准和分支覆盖标准。语句覆盖率标准是按照Reg.Guide 1.171中对核应用的建议选择的。根据Reg.Guide 1.171，我们应该在基于代码的测试中覆盖代码中的所有语句。
在这个测试中，分支覆盖标准也被选为一个更有力的标准。
为基于代码的单元测试生成测试数据的程序如下。

(1) 识别要测试的单元。
(2) 为确定的单元逐一生成自动代码。
(3) 为基于代码的单元测试选择测试数据。
- 对代码应用语句和分支覆盖标准。
- 选择数据

4.2 集成测试

集成测试的目的是检查当单元结合在一起时是否有任何错误。因此，它侧重于模块之间的接口。我们选择能够检测模块间接口信息的测试数据。选择集成测试数据的过程如下所示：
(1) 绘制状态组合图。

确定要组合成一个模块的单元。这在图4.2中显示。模块和单元分别用圆角矩形和椭圆表示。初始单元用一个带复选标记的椭圆表示，一个最终单元用两个椭圆表示。
单位之间的关系用虚线表示，模块之间的关系用实线表示。

(2) 在状态组合图中，一个状态代表单元或模块，而一个过渡则代表状态之间的通信关系。通过应用分支覆盖标准，我们可以覆盖状态组合图中的所有状态和分支。因此，通过应用分支覆盖标准选择的测试数据覆盖了状态分解图中的所有符号。

4.2.1 实时操作系统的状态组合图

(1) 确定组合成模块的单元图4.3是实时操作系统的状态组合图。有两个模块：
内核和任务模块。这些模块分别由两个和八个单元组成。
(2) 识别关系如图4.3所示，如果任务模块得到SYS_ON信号，任务模块中的 "任务 "单元会向内核模块发送TCB_RDY信号。然后，内核模块发送RUN_TSK信号来启动目标 "任务".

4.2.2 集成测试的测试数据

我们通过对模块间的转换关系应用分支覆盖标准来选择集成测试数据，如图4.3所示。图4.4中的粗线代表了对 "任务 "模块中的 "任务1 "单元应用分支覆盖标准的一个例子。如果 "Task1 "接收到一个 "SYS_ON=T "的信号，它就发出一个 "T1_TCB_RDY=T "的信号给内核模块。然后，内核模块发出一个\'RUN_TSK1=T\'信号来启动\'Task1\'。

我们通过应用分支覆盖标准，考虑到卫星分解图中的最终状态，在内核模块和任务模块之间产生七个测试数据。

4.3 系统测试

系统测试的目的是检查它是否显示出需求说明中描述的行为。在选择系统测试数据时，我们利用活动图。选择系统测试数据的程序如下：

(1) 从活动图中提取场景。
(2) 根据场景绘制序列图。
- 活动图的一个模块可以是序列图的一个类。
- 活动图的事件和数据可以是序列图的消息。
(3) 根据序列的数据流确定输入数据，选择系统测试数据。

4.3.1 场景

从活动图中提取的场景可以根据中断条件进行分类。这里，我们从没有中断的例子中生成测试数据。

4.3.2 顺序图

我们在活动图的基础上构成顺序图，如图4.5所示。

4.3.2 系统测试数据的选择

我们根据顺序图中的数据流，通过识别输入数据来选择系统测试数据。一种情况如图4.5所示，输入数据被显示为一组信号： SYS_ON，和T1_TCB_RDY ~ T4_TCB_RDY，可以形式化为如下：
系统测试数据 = (SYS_ON, T1_TCB_RDY, T2_TCB_RDY, T3_TCB_RDY,T4_TCB_RDY)
如果没有中断，总共有16个系统测试数据，如表4.3所示。如果选择定义为(T,F,T,T,T)的第15个系统测试数据，预期输出将是启动 "任务6"。

嵌入式系统测试

5.1 系统规范

在前面的章节中，我们展示了包括安全关键应用的RTOS软件验证在内的开发程序。在本节中，我们展示了测试，以确定当它被嵌入到硬件中时是否工作良好，同时也检查当它与应用软件集成时是否有任何错误。测试板是为此目的而设置的。所用的测试板有一个英特尔80C196kc CPU，有RS-232端口作为接口。由于开发的PLC是针对数字植物保护系统（DPPS）的，我们对简化的DPPS功能进行建模，并自动生成代码，与RTOS软件的程序相同。
DPPS接收每个变量的四个冗余输入，然后，将它们与定义的设定点进行比较。当输入超过设定点时，它产生 "真 "值作为输出。结果被传送到下一个模块，在那里收集每四个冗余通道的结果。如果四个监测变量中有两个以上的值显示为 "真"，那么它就会发出一个跳闸信号，启动保护功能。DPPS系统软件被简化，为了方便嵌入式系统测试，只对一个监测变量进行建模。

5.2 可靠性评估

结论

在这项工作中，我们展示了为安全关键的核应用指定、验证和测试实时操作系统的整体程序。对实时操作系统的要求进行了分析，得出的结论是可以验证的，因为实时操作系统所需的功能是简单和确定的。在验证之后，软件被自动生成C语言，这个生成的代码被测试用于每个目的。单元测试、集成测试和系统测试作为软件测试被执行。在单元测试中，我们进行了两种类型的测试；一种是基于代码的测试，看是否有任何错误，另一种是基于状态的测试，检查开发的软件是否满足验证模型的属性。在集成测试中，我们制定了状态组合图，并通过应用分支覆盖标准生成测试数据。在这个测试中，我们检查任何两个或更多的模块是否像我们在模型中设计的那样正常通信。在系统测试中，我们从需求规范中提取场景来检查整个系统的行为。在验证和测试之后，我们将嵌入式系统作为一个原型来实现。我们生成简化的应用软件嵌入到RTOS中，然后测试整个嵌入式系统，检查它在与应用软件和硬件集成时是否正常工作。我们计算出满足可靠性标准所需的测试次数，这将给我们带来量化的可靠性。

内嵌RTOS的DSP物联网方案

关注+星标公众号，不错过精彩内容

直接来源 | RTThread物联网操作系统

原文链接：

https://www.ceva-dsp.com/ourblog/iot-dsp-and-rtos-a-perfect-match/

物联网的快速发展超出了几乎所有人的想像，每天都有成千上万的设备入网。面对如此庞大的市场需求，传统技术早已不堪重负，而对新一代的数字信号处理提出了高运算能力和低功耗等更多要求。（本文的观点是，搭载RTOS的新一代混合型DSP技术，是物联网的最佳选择）

随着新市场及其对新技术需求的快速增长，一些技术的利用率越来越高。数字信号处理(DSP)就是这样一种技术，其形式可以是芯片，也可以作为系统级芯片(SoC)的IP核。虽然DSP已经存在很长时间了，但新一代DSP所支持的功能，对于满足某些特定市场需求来说非常重要，比如IoT(物联网)。鉴于许多物联网设备的固有性质，通常都会使用实时操作系统(RTOS)。

Ori Leibovich，CEVA嵌入式开发高级经理

DSP技术演进

DSP被用来转换和处理现实世界中的模拟信号，这种处理操作是通过复杂的信号处理算法来完成的。作为上世纪80年代就出现的技术，DSP在硬件功能和软件开发工具以及基础设施方面，已取得很大发展。早年的算法是用汇编语言编程到DSP上的。随着DSP市场的扩大以及算法变得越来越复杂，其架构也在不断发展，并促进了高级语言编译器的开发。

带嵌入式DSP内核的芯片，一般都集成有片内存储器，其大小通常足以容纳执行专用任务所需的整套程序。新一代DSP应用范围涵盖了音频/语音处理、图像处理、电信信号处理、传感器数据处理和系统控制等。而如今的物联网市场，则几乎覆盖了之前众多用例的各种组合。行业分析公司Markets and Markets预计，到2027年，全球物联网技术市场规模将增长到5664亿美元。面对如此庞大的物联网市场，新一代的DSP技术至关重要。

为什么DSP非常适合物联网设备？

物联网通过使用不同类型的传感器收集数据，实现现实世界中万物间的通信和连接。DSP对来自传感器的连续变化信号进行分析和处理。如今，已出现传感器hub DSP(如CEVA-SensPro2)，就是用来处理和融合多个传感器信息的，并用于上下文感知的神经网络推理。DSP设计用于分析和处理音视频、温度、压力或湿度等现实世界中的各类信号，其任务涉及精确和准确的实时重复数字计算。随着物联网市场的增长，越来越多的传感器得到部署，收集到的所有数据都需要得到高效的实时处理。如今越来越清晰的迹象表明，数据处理需要在物联网设备上直接进行，而不是将其发送到云端进行处理。

目前正在发生的另一个事关物联网设备的趋势是，越来越多地使用基于人工智能(AI)的算法完成数据的本地化处理。人工智能算法基于神经网络模型，需要高水平的并行能力才能有效执行。并行计算能力是DSP优于通用中央处理器(CPU)的一个关键优势。为了满足这一要求，现代DSP架构倾向于使用宽向量和单指令多数据(SIMD)功能。

简而言之，基于DSP的强大解决方案，可以同时满足现代物联网设备的高性能计算和低功耗需求。

为什么DSP与RTOS很匹配？

正如DSP是一种专用处理器一样，RTOS也是一种专用操作系统。DSP致力于极其快速和可靠地处理现实世界的数据，而RTOS则致力于可靠地满足响应/反应时间方面的特定时序要求。DSP与通用CPU相比更紧凑，RTOS与常规操作系统相比也是如此。这些特性完全符合物联网设备的需求，因而使得DSP和RTOS成为物联网应用的理想之选。

从历史上看，嵌入式设备一般会利用一个专门用途、通常为8位或16位的微控制器，可以在没有RTOS的情况下工作。但如今的物联网设备更加复杂，需要一个32位CPU与带有RTOS的DSP相结合，来管理控制功能，并运行复杂的信号处理。

但问题是，新一代DSP是否足以同时完成物联网设备的信号处理和控制功能？答案是肯定的。一种能够提供面向DSP功能和面向控制器功能的混合DSP架构，正在迅速被物联网和其他嵌入式设备所采用。这种混合DSP具有支持超低指令字(VLIW)架构实现、单指令多数据(SIMD)操作、单精度浮点运算、紧凑的代码规模、全RTOS、超快速上下文切换、动态分支预测等特点，从而设备上不再需要额外的处理器来运行RTOS。

面向DSP的RTOS

基于DSP的RTOS旨在充分利用DSP的高性能特性。它是一个先占式、基于优先级的多任务操作系统，可提供非常低的中断延迟。这类RTOS附带驱动程序、应用程序编程接口(API)、以及为DSP芯片定制的DSP功能运行芯片支持库(CSL)。所有片上外设都可以被控制，比如高速缓存、直接内存访问(DMA)、定时器、中断单元等。因此，物联网应用程序开发人员能够轻松地配置RTOS，从而高效处理资源请求和管理系统。

面向物联网的RTOS：RT-Thread

RT-Thread是一款专为物联网设备优化的开源RTOS，资源占用率极低、可靠性高、可扩展性强。RT-Thread得到物联网设备所需丰富的中间件、硬件以及软件生态系统的广泛支持。

RT-Thread支持GCC、Keil、IAR等所有主流编译工具，支持POSIX、CMSIS、C++应用环境、以及Micropython、Javascript等多种标准接口。

RT-Thread还为所有主流CPU和DSP架构提供强大的支持。通过RTOS消息传递线程间的通信和同步、信号旗语等业务可得到始终如一的高效处理。

目前，RT-Thread有两个版本。一个是用于资源丰富的物联网设备的标准版，而另一个则为Nano版，用于资源受限的系统。

DSP与RT-Thread的完美结合

某些DSP(如CEVA DSP)架构设计，原生就支持RTOS功能和超快速上下文切换，因此使用CEVA DSP和RT-Thread RTOS实现的物联网设备，可以不中断RTOS，同时处理不同资源之间的多种通信任务。例如，多核通信接口(MCCI)机制支持内核之间的命令通信和消息传递。内核之间的通信是通过使用AXI从端口直接访问专用命令寄存器来实现的。DSP有专门的控制和指令，可以通过MCCI跟踪通信的状态。

多核通信接口架构。(来源：CEVA)

通过使用均为32位的MCCI_NUM专用命令寄存器来执行内核之间的消息传递。32位COM_REGx寄存器由外部内核通过AXI从端口写入，内核只能读取。对于128位AXI总线，命令生成内核可以同时写入的寄存器多达四个，而对于256位AXI总线，该数目则增至八个。

当生成命令的内核将命令输出到COM_REGx时，寻址寄存器将会被更新，COM_STS寄存器中的相关状态位也会被更新。此外，中断(MES_INT)将被确认以通知接收内核。

当接收内核读取其中一个COM_REGx寄存器后，会向发起方发送一个读取指示信号。读取指示信号由接收内核使用专用的RD_IND(读取指示)MCCI_NUM位总线接口发送。RD_IND总线的每一位分别表示来自其中一个COM_REGx寄存器的读取操作。利用IO接口，接收内核一次只能读取一个COM_REGx寄存器。这样不仅使不同内核间同步变得更简单，而且使同一内核中不同任务间的同步也变得更为容易。

------------ END ------------