一种嵌入式操作系统设计层形式化验证方法与流程

文档序号:31795083发布日期:2022-10-14 17:08阅读:121来源:国知局
一种嵌入式操作系统设计层形式化验证方法与流程

1.本发明涉及一种嵌入式操作系统设计层形式化验证方法,属于嵌入式操作系统领域。


背景技术:

2.随着航天事业的迅猛发展,空间任务的规模及复杂度上升,空间飞行器上的软件规模也随之增加。这就对硬件提出更高的要求,但是空间计算机硬件资源有限,如何使计算机硬件资源得到更有效地利用就成为一个关键难题。因此,引入空间操作系统就成为了必然趋势。操作系统是紧靠硬件的第一层软件,是所有高层应用软件运行的支撑和基础,是计算机系统里最重要的软件。操作系统中的任何一个微小的错误都可能导致整个系统的崩溃,因此操作系统应该是一个高可靠、高可信的软件系统,这是保证所有应用软件能可靠运行的基础。传统软件开发方法为了避免错误的出现,采用软件测试的方法来检测软件中可能存在的隐患。测试要依靠测试人员设计测试用例,经过长时间的大量测试来检测系统是否有错误,可靠性和可信性只能靠堆积测试时间和测试量来加强。然而软件测试只能发现问题,不能确保测试用例涵盖所有情况,因此不能保证系统没有问题。
3.形式化方法是建立在严格数学基础上的用以对软硬件系统进行说明、设计和验证的语言、技术和工具的总称,形式化验证是使用逻辑推理来保证计算机程序正确性的方法之一,可以通过形式化的程序逻辑来验证一个程序是否满足已给定的规范。对于空间飞行器来说,安全性是第一要素。操作系统是管理飞行器系统的基础核心,决定了硬件系统是否能够正常运行,应用软件是否能够完成预定任务。因此空间操作系统的形式化验证具有重大的理论和实际意义。
4.目前,针对操作系统这类大型软件的正确性保障,主要通过人工走查、软件测试等方式进行;国内外已有的对于操作系统的形式化验证,主要针对单一模块的代码进行验证,缺乏对操作系统设计层的验证,难以从源头发现潜在的错误;缺少对操作系统整体的形式化验证方法,无法降低大规模操作系统软件的验证难度。设计层作为软件工程中重要的一个阶段,其正确性直接影响最终操作系统软件的安全性与可信性,对其进行形式化验证能够更早地发现在设计阶段是否有潜在的错误。


技术实现要素:

5.本发明解决的技术问题是:克服现有技术的不足,提供了一种嵌入式操作系统设计层形式化验证方法,确保根据设计文档准确地描述操作系统的运行过程,并且验证其是否满足正确性要求,以便更早地发现是否有潜在的错误,有助于完成整个操作系统的形式化验证。
6.本发明的技术解决方案是:
7.一种嵌入式操作系统设计层形式化验证方法,包括:
8.从操作系统详细设计报告中,获取操作系统包含的函数模块、各函数模块的具体
功能及流程图,提炼操作系统各函数模块应满足的局部性质;
9.根据函数模块构建操作系统的系统状态及确立引起系统状态变化的触发事件;
10.建立基于有限状态机的操作系统设计层形式化模型;
11.在定理证明器coq中将提炼出的局部性质和操作系统设计层形式化模型进行形式化定义,验证操作系统设计层形式化模型是否满足所述局部性质,若满足,则所述操作系统设计层正确可靠;若不满足,根据不满足的局部性质确定详细设计报告中存在问题的流程图及问题的具体位置。
12.优选的,按照如下方式提炼操作系统某个函数模块应满足的局部性质:
13.结合该函数模块的具体功能,根据其流程图的不同分支,从成功和失败两方面考虑,分别提炼出执行其流程图成功或者失败分支应满足的性质,作为该函数模块应满足的局部性质。
14.优选的,所述操作系统包含的函数模块包括任务管理模块、中断管理模块、内存管理模块、时间管理模块、任务间通信模块,以及各函数模块下细分的子函数模块。
15.优选的,根据函数模块构建的系统状态,包括该函数模块的输入、输出、以及该函数模块对应的流程图中涉及的关键变量,所述关键变量是指其取值不同时导致流程图进入不同分支的变量。
16.优选的,不同函数模块对应的流程图,从开始到结束,每次从一个流程框转移到另一个流程框的条件,确立为引起系统状态变化的一种触发事件。
17.优选的,将所有函数模块的输入、输出和流程图中涉及的关键变量作为有限状态机的状态,触发事件作为有限状态机的状态转移条件,建立基于有限状态机的操作系统设计层形式化模型,在该模型中,随着触发事件的发生,导致状态的一个或多个组成元素发生改变,最终引起状态发生改变。
18.优选的,在定理证明器coq中对操作系统设计层形式化模型进行形式化定义,包括:
19.定义基本数据类型表征系统状态,所述基本数据类型包括输入状态、输出状态、各种关键变量;
20.定义状态转移函数表征触发事件,所述状态转移函数包括转移前状态、状态转移条件、转移后状态。
21.优选的,在定理证明器coq中定义局部性质的方式是:
22.从系统状态中提取局部性质涉及到的数据结构,提取后描述所述数据结构之间的关系。
23.优选的,验证操作系统设计层形式化模型是否满足局部性质的方式如下:
24.采取证明策略,将coq中形式化定义的局部性质在操作系统设计层形式化模型中进行逐步简化和推理,直到所述局部性质被证明完成或中断;
25.若证明完成,则所述操作系统设计层形式化模型满足所述局部性质,操作系统设计层正确可靠;如证明中断,则所述操作系统设计层形式化模型不满足所述局部性质,找出对应的局部性质,据此提取设计报告流程图中存在的问题。
26.一种嵌入式操作系统设计层形式化验证系统,包括:局部性质获取模块、操作系统设计层形式化模型建立模块、操作系统设计层形式化模型验证模块;
27.局部性质获取模块:从操作系统详细设计报告中,获取操作系统包含的函数模块、各函数模块的具体功能及流程图,并提炼操作系统各函数模块应满足的局部性质,将上述获取和提炼的内容发送给操作系统设计层形式化模型建立模块和操作系统设计层形式化模型验证模块;
28.操作系统设计层形式化模型建立模块:根据函数模块构建操作系统的系统状态及引起系统状态变化的触发事件,据此建立基于有限状态机的操作系统设计层形式化模型,发送给操作系统设计层形式化模型验证模块;
29.操作系统设计层形式化模型验证模块:在定理证明器coq中将局部性质和操作系统设计层形式化模型进行形式化定义,验证操作系统设计层形式化模型是否满足所述局部性质,若满足,则所述操作系统设计层正确可靠;若不满足,根据不满足的局部性质确定详细设计报告中存在问题的流程图及问题的具体位置。
30.本发明与现有技术相比具有如下优点:
31.(1)本发明提供的一种嵌入式操作系统设计层形式化验证方法,从操作系统详细设计入手,在设计层进行合理抽象,针对操作系统设计的函数模块提炼对应局部性质并建立了基于有限状态机的操作系设计层形式化模型,可以准确地描述操作系统的设计过程和各模块的运行过程;判断所建立模型是否满足所提炼的局部性质,若满足,则所述操作系统设计层正确可靠;如不满足,找出对应性质,发现设计报告流程图存在问题;给出机器可检查的证明,可以快速定位缺陷所在;克服了现有技术仅针对部分源代码的验证的不足,有助于更早地发现是否有潜在的错误,完成整个操作系统的形式化验证,在代码测试之前发现并解决潜在错误。
32.(2)针对设计流程图进行形式化建模,可以反映操作系统最基本的行为特征,针对安全关键系统的操作系统模式可以完全覆盖,既简化了系统模型,又涵盖了所有核心要素,便于建模与验证;克服了现有技术难以验证大规模软件的问题,简化了操作系统验证难度。
33.(3)本发明不仅适用于航天器操作系统,对其他嵌入式安全关键系统同样适用,具有良好的复用性、适应性和灵活性。
附图说明
34.图1为本发明实施例提供的一种嵌入式操作系统设计层形式化验证方法的流程图;
35.图2为本发明实施例提供的一种嵌入式操作系统设计层形式化验证方法的一具体实例的流程图-任务调度;
36.图3为本发明实施例提供的有限状态机模型的状态转移图;
37.图4为本发明提供的一种嵌入式操作系统设计层形式化验证方法的验证过程图。
具体实施方式
38.以下将结合附图和具体实施例对本发明的具体实施方式做进一步详细说明。
39.一种嵌入式操作系统设计层形式化验证方法,包括:
40.响应于对操作系统设计层进行验证的请求,从操作系统详细设计报告中,获取操作系统对应的多个函数模块、各函数模块对应的具体功能及流程图,结合函数功能要求,根
据流程图的不同分支,提炼对应的局部性质。然后构建操作系统的系统状态及确立引起系统状态变化的触发事件;根据确定的系统状态及引起系统状态变化的触发事件,建立基于有限状态机的操作系统设计层形式化模型;最后在定理证明器coq中将提炼出的局部性质以及建立的形式化模型进行形式化定义,并验证建立的系统模型是否满足这些局部性质,给出机器可检查的证明;若满足,则所述操作系统设计层正确可靠;如不满足,找出对应性质,发现设计报告流程图存在的问题。
41.实施例:
42.如图1所示,本发明实施例提供了一种嵌入式操作系统设计层形式化验证方法,包括:
43.步骤101:响应于对操作系统设计层进行验证的请求,从操作系统详细设计报告中,获取操作系统包含的函数模块、各函数模块对应的具体功能及流程图,提炼操作系统各函数模块应满足的局部性质。
44.按照如下方式提炼操作系统某个函数模块应满足的局部性质:
45.结合该函数模块的具体功能,根据其流程图的不同分支,从成功和失败两方面考虑,分别提炼出执行其流程图成功或者失败分支应满足的性质,作为该函数模块应满足的局部性质。例如当某关键变量不满足约束条件时,导致该函数功能提前终止,则提炼出“某变量不能超出某范围,否则该功能失败或终止”的性质;当流程图顺利走通时,则根据走通路径中涉及到的变量提炼出最终该功能成功实现时应满足的性质。
46.具体地,本发明实施例中,操作系统可以按功能划分为七个部分:初始化、任务管理、中断管理、时间管理、内存管理、任务间通信管理和外设管理等七个函数模块,选取任务管理模块下细分的子函数-任务调度函数作为对象,任务调度函数的功能是在任务调度点按照策略选择最合适的任务执行。结合图2任务调度的流程图从成功和失败两方面考虑,任务调度提炼局部性质如下:
47.(1)系统调度上锁,则终止本次任务调度;
48.(2)任务调度在中断服务程序中运行,则终止本次任务调度;
49.(3)任务调度完成后,允许中断;
50.(4)任务调度进行任务的上下文切换。
51.步骤102:针对各函数模块构建对应的系统状态,包括该函数模块的输入、输出、以及该函数模块对应的流程图中涉及的关键变量,所述关键变量是指其取值不同时导致流程图进入不同分支的变量。
52.具体地,本发明实施例中,任务调度流程中对应的关键变量是调度上锁标志、中断开关、中断嵌套标志、任务状态、调度标志和上下文切换标志,因此选择六元组定义系统状态:
53.{调度上锁标志lockflag,中断嵌套标志intflag,中断开关interrupt,任务状态taskstate,调度标志schedflag,上下文切换标志swtich};
54.步骤103:根据不同函数模块对应的流程图,从开始到结束,每次从一个流程框转移到另一个框的条件,确立为引起系统状态变化的一种触发事件即为有限状态机的状态转移条件。
55.具体地,本发明实施例中,任务调度流程图中涉及到的框图转换条件包含以下几
种:系统调度上锁、系统调度未上锁、任务调度函数在中断服务程序中运行、任务调度函数不在中断服务程序中运行、关中断、调用任务重调度函数、开中断,即为有限状态机的状态转移条件。
56.步骤104:函数模块的输入、输出和流程图中涉及的关键变量组成系统状态,触发事件作为有限状态机的状态转移条件,建立基于有限状态机的操作系统设计层形式化模型,在该模型中,随着触发事件的发生,组成系统状态中的一个或多个元素发生改变,导致系统状态发生改变。
57.具体地,如图3所示,根据确定的系统状态及引起系统状态变化的触发事件,建立基于有限状态机的操作系统设计层形式化模型,包括:
58.操作系统在开始任务调度之前,处于初始状态s0,此时调度上锁标志lockflag默认为false;中断嵌套标志intflag默认为false;因为此时允许中断,所以中断开关interrupt为on;任务为就绪态等待调度,因此任务状态taskstate为ready;尚未完成调度,调度标志schedflag为false;未发生任务上下文切换,上下文切换标志ctxswitch为false;
59.当判断调度上锁标志时,若系统调度上锁,则本次终止任务调度,直接返回初始状态s0;
60.当判断调度上锁标志时,若系统调度未上锁,则置lockcntflag为true,进入下一状态s1;
61.当判断是否在中断中调用任务调度时,若任务调度函数在中断服务程序中运行,则本次终止任务调度,置lockcntflag为false,返回初始状态s0;
62.当判断是否在中断中调用任务调度时,若任务调度函数不在中断服务程序中运行,则置intcntflag为true,进入下一状态s2;
63.关中断事件发生时,置中断开关interrupt为off,不响应中断,进入下一状态s3;
64.调用任务重调度函数事件发生时,置调度标志schedflag为true,进入状态s4;
65.开中断事件发生时,置中断开关interrupt为on,响应中断,进入下一状态s5;
66.任务上下文切换事件发生时,更新系统状态中的上下文切换标志ctxswitch为true,进入状态s6,完成任务调度。
67.步骤105:根据建立的形式化模型,在辅助定理证明工具coq中对操作系统设计层形式化模型进行形式化定义,包括:
68.定义基本数据类型表征系统状态,所述基本数据类型包括输入状态、输出状态、各种关键变量;
69.定义状态转移函数表征触发事件,所述状态转移函数包括转移前状态、状态转移条件、转移后状态。
70.具体地,本发明实施例中,定义任务调度对应的有限状态机模型,包括系统状态rdata,状态转移条件event和状态转移函数transfer等。
[0071][0072][0073]
步骤106:在辅助定理证明工具coq中定义对应的局部性质,具体方式是将性质涉及到的数据结构从系统状态中取出,然后描述这些数据结构之间的关系。并根据建立的基于有限状态机的操作系统设计层形式化模型,验证是否满足提出的局部性质,首先明确证明目标,即在coq中形式化定义的局部性质;然后采取恰当的证明策略,将复杂的目标进行逐步简化和推理,直到提出的性质被证明完成或中断,包括:
[0074]
若证明完成,则所述模型满足所述局部性质,所述操作系统设计层正确可靠;如证明中断,则所述模型不满足所述局部性质,找出对应性质,发现设计报告流程图存在问题。如图4所示。
[0075]
具体地,本发明实施例中,对性质1“系统调度上锁,则终止本次任务调度”进行形式化定义如下:
[0076]
lemma locknesting:forall state lock,p0 lock-》some state=transfer(checklock lock)s0-》end_sched state.
[0077]
然后采用合适的证明策略,进行验证目标的推理及求解,逐步化简证明,直到提出的性质被证明完成或中断。本实施例中4条局部性质均验证完成,说明所述模型满足所述局部性质,操作系统的任务调度模块正确可靠。
[0078]
本发明具有良好的复用性、适应性和灵活性,可以准确地描述操作系统的设计过程,有助于更早地发现是否有潜在的错误,在代码测试之前发现并解决潜在错误,确保操作系统的安全性和可信性。
[0079]
以上所述,仅为本发明一个具体实施方式,但本发明的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本发明揭露的技术范围内,可轻易想到的变化或替换,都应涵盖在本发明的保护范围之内。
[0080]
本发明未详细说明部分属于本领域技术人员公知常识。
当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1