CN114385501A - 一种安全关键软件验证方法、装置、设备及介质 - Google Patents
一种安全关键软件验证方法、装置、设备及介质 Download PDFInfo
- Publication number
- CN114385501A CN114385501A CN202210031298.7A CN202210031298A CN114385501A CN 114385501 A CN114385501 A CN 114385501A CN 202210031298 A CN202210031298 A CN 202210031298A CN 114385501 A CN114385501 A CN 114385501A
- Authority
- CN
- China
- Prior art keywords
- software
- model
- verification
- safety
- requirement specification
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3604—Software analysis for verifying properties of programs
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/10—Requirements analysis; Specification techniques
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Stored Programmes (AREA)
Abstract
本发明属于软件测试验证技术领域,提供了一种安全关键软件验证方法、装置、设备及介质。其中,方法包括:基于LTL语言扩展FTA模型得到形式化的系统安全性约束条件及对应的软件需求规范;将软件需求规范按照预制定转换规则和MBD的软件规范符号匹配,使软件需求规范转化为安全规约模型;将安全规约模型和预生成的SCADE软件设计模型输入模型验证器,完成对软件的安全性验证。采用本申请实施例的技术方案,通过LTL语言进行扩展使安全性约束条件和安全性约束条件对应的软件需求规范满足形式化特征,同时依据预制定的转换规则使软件需求规范可以转化为安全规约模型,用以输入模型验证器中进行验证,避免了安全性验证方法的人为因素的干扰,提高了可靠性。
Description
技术领域
本发明涉及软件测试验证技术领域,具体涉及一种安全关键软件验证方法、装置、设备及介质。
背景技术
现代安全关键电子系统正向软件密集型系统转变。软件在系统中所承担功能的占比持续增加,导致软件安全性对系统的安全至关重要。因此,探索一种符合发展趋势且合理的软件验证方法成为了迫切需要,而如何针对复杂软件进行有效验证,成为软件安全性工作的难点。
目前主流的软件安全性验证方法为通过安全性分析方法捕获软件的安全性需求,结合形式化验证技术完成对软件的验证工作。采用的形式化验证技术包括定理证明技术和模型检验技术。
定理证明的主要思想是:将系统模型和待验证性质逻辑化,用公式表示出来,根据严格的推理过程,由系统模型推导出待验证性质进而证明系统模型的正确性。采用定理证明的方法能够处理系统无限的状态空间,不存在空间爆炸问题。但定理证明的过程中需要了解整个系统和待验证性质的大量信息,增加了对验证人员的知识要求和能力要求,同时定理证明的方法未能实现完全的自动化,验证过程中需要人工辅助进行,验证效率低,难以在大型复杂系统的形式化验证中应用。因此定理证明主要用于科研研究领域,并没有在工业领域得到广泛的应用。而模型检验技术用于针对有限状态,通过有穷状态空间搜索系统的整个状态空间来检查该系统是否满足给定的性质,而传统的软件开发模式以代码为核心,对模型进行验证时,必须花费大量工作在建造模型上,同时需要开发者针对形式化验证语言验证流程特别熟悉,大大加大了开发的时间和精力。
发明内容
针对现有技术中的缺陷,本发明提供一种安全关键软件验证方法,以解决现有技术验证时在建造模型上花费大量工作,且对验证人员要求高,及人为干扰因素大的问题。
第一方面,本发明提供的一种安全关键软件验证方法,包括:
基于LTL语言扩展FTA模型得到形式化的系统安全性约束条件及对应的软件需求规范;
将所述软件需求规范按照预制定转换规则和MBD的软件规范符号匹配,使所述软件需求规范转化为安全规约模型;
将所述安全规约模型和预先生成的SCADE软件设计模型输入模型验证器,完成对软件的安全性验证。
由上述技术方案可知,本发明提供的安全关键软件验证方法,通过LTL语言进行扩展,使安全性约束条件和安全性约束条件对应的软件需求规范满足形式化特征,同时依据预制定的转换规则,使软件需求规范可以转化为安全规约模型,用以输入模型验证器中进行验证,避免了安全性验证方法的人为因素的干扰,提高了可靠性。
可选地,所述基于LTL语言扩展FTA得到规范化的系统安全性约束条件及对应的软件需求规范,包括:
获取FTA的最小割集X,并确定FTA中顶事件T和最小割集X之间的关系;
获取针对于顶事件T和最小割集X的故障树的安全性约束条件及与所述安全性约束条件对应的软件需求规范。
可选地,所述顶事件T关于所述最小割集X的关系表达式为
其中,式中∑代表并集,II代表交集,Xi代表第i个最小割集。
可选地,所述软件需求规范与安全规约模型的预制定转换规则为
其中,“\”表示没有对应的形式化建模符号。
可选地,所述SCADE软件设计模型的生成方法,包括:
以设计文档作为输入,基于SCADE完成待开发软件的设计实现,输出软件设计模型。
可选地,所述SCADE软件的安全性验证包括如下步骤:
通过形式化验证器完成软件的验证,若验证通过,则软件设计模型符合软件安全需求,否则输出用于修改SCADE软件设计模型的反例。
第二方面,本发明提供的安全关键软件验证装置,包括:
规范生成模块,用于基于LTL语言扩展FTA模型得到形式化的系统安全性约束条件及对应的软件需求规范;
模型转换模块,用于将所述软件需求规范和MBD软件规范软件模范符号匹配,使所述软件需求规范转化为安全规约模型;
验证模块,用于将所述安全规约模型和完成预验证的SCADE软件设计模型输入模型验证器,完成对软件的安全性验证。
可选地,所述规范生成模块,具体用于:
获取FTA的最小割集X,并确定FTA中顶事件T和最小割集X之间的关系;
获取针对于顶事件T和最小割集X的故障树的安全性约束条件及与所述安全性约束条件对应的软件需求规范。
可选地,所述规范生成模块中所述顶事件T关于所述最小割集X的关系表达式为
其中,式中∑表示并集,II表示交集,Xi表示第i个最小割集,Cj表示第j个中间事件,r表示中间事件的个数。
可选地,所述模型转换模块中,所述软件需求规范与安全规约模型的预制定转换规则为
其中,“\”表示没有对应的形式化建模符号。
可选地,所述验证模块中所述SCADE软件设计模型的生成方法,包括:
以设计文档作为输入,基于SCADE完成待开发软件的设计实现,输出软件设计模型。
可选地,所述验证模块,具体用于:
通过形式化验证器完成软件的验证,若验证通过,则软件设计模型符合软件安全需求,否则输出用于修改SCADE软件设计模型的反例。
第三方面,本发明一实施例提供了一种电子设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,其中,处理器执行计算机程序时实现上述任一种方法的步骤。
第四方面,本发明一实施例提供了一种计算机可读存储介质,其上存储有计算机程序指令,该计算机程序指令被处理器执行时实现上述任一种方法的步骤。
采用上述技术方案,本申请具有如下技术效果:
本发明提供的安全关键软件验证方法,通过LTL语言进行扩展,使安全性约束条件和安全性约束条件对应的软件需求规范满足形式化特征,同时依据预制定的转换规则,使软件需求规范可以转化为安全规约模型,用以输入模型验证器中进行验证,避免了安全性验证方法的人为因素的干扰,提高了可靠性。同时对于输入验证器的安全规约模型和软件设计模型,在验证未通过的情况下,验证器会自动生成反例,以及该反例的路径信息,以便于错误分析及定位。
基于FTA的软件验证方法,由于其基于链式/树式事故因果模型的安全性分析技术,在分析特性事故发生原因方面具备一定优势,可以具体到因此在针对特定事故且系统耦合度较低的软件安全性分析中,选用FTA方法进行安全性分析,可提高工作强度。
附图说明
为了更清楚地说明本发明具体实施方式或现有技术中的技术方案,下面将对具体实施方式或现有技术描述中所需要使用的附图作简单地介绍。在所有附图中,类似的元件或部分一般由类似的附图标记标识。附图中,各元件或部分并不一定按照实际的比例绘制。
图1示出了本发明实施例提供的一种安全关键软件验证方法的流程图;
图2示出了本发明实施例提供的起落架控制结构原理图;
图3示出了本发明实施例提供的起落架控制系统故障树模型的示意图;
图4示出了本发明实施例提供的安全规约模型的示意图;
图5示出了本发明实施例提供的起落架控制器软件设计模型的示意图;
图6示出了本发明实施例提供的软件验证的流程示意图;
图7示出了本发明实施例提供的一种安全关键软件验证装置的结构框图;
图8示出了本发明实施例提供的电子设备的示意图。
具体实施方式
下面将结合附图对本发明技术方案的实施例进行详细的描述。以下实施例仅用于更加清楚地说明本发明的技术方案,因此只是作为示例,而不能以此来限制本发明的保护范围。
需要注意的是,除非另有说明,本申请使用的技术术语或者科学术语应当为本发明所属领域技术人员所理解的通常意义。
为了方便理解,下面对本发明实施例中涉及的名词进行解释:
FTA(Fault Tree Analysis,故障树分析),是由上往下的演绎式失效分析法,利用布林逻辑组合低阶事件,分析系统中不希望出现的状态。故障树分析主要用在安全工程以及可靠度工程的领域,用来了解系统失效的原因,并且找到最好的方式降低风险,或是确认某一安全事故或是特定系统失效的发生率。
LTL(Linear Temporal Logic,线性时序逻辑),常作为描述系统行为的性质语言,被引入计算机领域非终止程序的行为规范语言。其具体问题描述是:给定一个程序模型M和它的行为规范φ,如何证明(验证)M的所有行为都能满足规范性质φ?目前主要有两种方案,一是定理证明(theorem proving),另一种是模型检验。本申请中主要涉及模型检验,即采用穷举的方式对整个M的状态空间遍历,检查是否它的所有行为都满足φ。模型检查方法的一个优势是它可以使用自动化的算法指导检查的过程,直到找到模型中违背性质φ的反例(counterexample)或是遍历结束。
MBD(Model-Base Design,基于模型的设计),是一种使用模型来表达软件需求和/或设计,并且进行后续软件开发和验证活动的技术。在实际项目中,可以使用模型来描述部分或全部软件需求,也可以使用模型来描述部分或全部设计,或者使用模型同时表达软件需求和设计。根据文字描述的软件需求进行建模,以模型来表达软件功能(包括软件架构和低级别需求),再通过专用的工具(如SCADE)直接生成源代码。
SCADE(Safety Critical Application Development Environment,安全关键应用开发环境),是一种高安全性嵌入式软件的开发环境。
传统的软件开发模式以代码为核心,对模型进行验证时,必须花费大量的工作在建造模型上,同时需要开发者针对形式化验证语言验证流程特别熟悉,增加了开发时间。如今,基于模型的软件开发方法,将传统的以代码为核心的开发方式转化为以模型为基础的开发方式,采用图形化的建模方式,降低了开发的难度,促进了形式化验证在工业领域的应用。本申请针对机载电子设备领域的发展特点,结合安全关键软件的研制工作,以模型为核心,对软件的验证技术进行了创新。
图1示出了本发明实施例所提供的一种安全关键软件验证方法的流程图。如图1所示,根据本发明实施例的安全关键软件验证方法包括:
S110、基于LTL语言扩展FTA模型得到规范化的系统安全性约束条件及对应的软件需求规范。
具体地,传统的故障树分析是以一个不希望发生的系统失效时间(顶事件)作为分析的目标,先去寻找所有引起顶事件的直接原因,再去寻找引起每一个原因的直接原因,依次层层寻找,直至不需要进一步分析为止,以此方式找出系统内部可能发生的硬件失效、软件缺陷、认为失误及环境影响等因素(底事件)和顶事件所代表的系统失效之间的逻辑关系,并用逻辑门符号连成一颗倒立的树状图形。
FTA建立的故障树模型,最终形成安全系统安全属性。但由于系统安全属性作为文字描述的需求,无法被识别,所以需要将软件需求规范转换为需要进行形式化扩展,本申请基于LTL语言完成形式化扩展。本步骤对FTA方法基于LTL语言进行了形式化扩展,将分析得到的最小割集进行了规范化表述。通常,FTA是通过分析最小割集生成系统安全性约束条件,指导系统的设计和测试。但是该过程缺乏规范化的表述方式,为了使需求分析规范化的指导系统设计和测试,采用形式化的方式扩展FTA得到规范化的系统安全性约束条件,规范化的系统安全性约束条件需要满足一定的规范。
可选地,步骤S110,具体包括:
S111、获取FTA的最小割集X,并确定FTA中顶事件T和最小割集X之间的关系。
S112、获取针对于顶事件T和最小割集X的故障树的安全性约束条件及对应的软件需求规范。
通常,FTA是通过分析最小割集生成系统安全性约束条件,指导系统的设计和测试。但是该过程缺乏规范化的表述方式,为了使需求分析规范化的指导系统设计和测试,满足后续的验证需求,采用形式化的方式扩展FTA得到规范化的系统安全性约束条件,规范化的系统安全性约束条件需要满足一定的规范。本实施例具体通过依据FTA形成安全约束条件,具体的关系表达式参见如下定义:
定义1:对于FTA定性分析得到的最小割集,可采用一个二元组SRi,j={Xi,T},表示顶事件T和最小割集X之间的关系,关系式表示如下:
式中∑代表并集;II代表交集;Xi代表第i个最小割集,Xi表示第i个最小割集,Cj表示第j个中间事件,r表示中间事件的个数。
通过上述定义,基于FTA生成形式化的表述方式,使需求分析可以规范的指导系统设计和测试,更便于后续的软件开发和验证,提高了软件验证的效率。
起落架控制系统作为典型的安全关键系统,由于其对飞行安全有至关重要的影响,下面以起落架作为一个具体示例,参见图2,图2为起落架控制结构原理图,图2中示出的起落架为前三点式起落架布局,通过飞行控制系统发出控制指令,采用闭环的控制方式完成起落架舱门开闭和起落架收放功能。软件主要通过控制各机构对应的电子阀门的开闭,来联通相应的液压回路,进而实现对油缸的控制,通过作动筒完成对被控对象的控制。被控对象的状态会通过各个机构上的三余度的传感器反馈给软件,从而进行下一步的控制。
根据起落架控制结构原理,得到如图3所述的起落架控制系统故障树模型,根据FTA方法识别出导致事故发生的基本原因,由此根据定义1和定义2捕获软件的安全需求规范。
S120、将软件需求规范按照预制定转换规则和MBD的软件规范符号匹配,使软件需求规范转化为安全规约模型。
由上述定义1和定义2可得到基于FTA形式化表述的软件需求规范,通过LTL语言描述的软件需求规范可以和MBD技术中的软件模型符号进行匹配,将软件需求规范转化为安全规约模型,参见图4,图4即为本申请实施例中提供的安全规约模型的示意图,基于模型来表达软件设计和/或需求,便于后续软件的开发和验证工作的进行。
可选地,软件需求规范与安全规约模型的预制定转换规则为
其中,“\”表示没有对应的形式化建模符号,但是在执行模型检测过程中穷尽了所有测试场景,包含了LTL中的任意时刻算子的作用。
模型检验是形式化验证技术的一种,可自动识别软件设计模型所有可能的输入情况,并探索在所有场景下软件可能输出的结果,验证软件模型是否有不符合安全规约的异常输出。
本发明所涉及到的MBD(Model-Base Design,基于模型的设计)技术是一种使用模型来表达软件需求和/或设计,并且进行后续软件开发和验证活动的技术。在实际项目中,可以使用模型来描述部分或全部软件需求,也可以使用模型来描述部分或全部设计,或者使用模型同时表达软件需求和设计。根据文字描述的软件需求进行建模,以模型来表达软件功能(包括软件架构和低级别需求),再通过专用的工具(如SCADE)直接生成源代码。
具体地,软件需求规范和MBD软件规范软件模范符号匹配,为了使确定的软件需求规范可以被SCADE识别,需要对软件需求规范转化为一定的转换规则进行转换。在开发过程中,软件需求规范对应于FTA模型中最小割集,为判断软件中不符合开发需求或存在异常行为的依据,保证了软件在开发过程中的安全性。
S130、将安全规约模型和生成的SCADE软件设计模型输入模型验证器,完成对软件的安全性验证。
模型检验是确定模型的正确性、有效性和可信性的研究和测试过程。一般包括两方面:一是验证所建模型即建模者构想中的模型;二是验证所建模型能够有效反映真实系统的行为特征。
具体地,在步骤S120中获取到的安全规约模型,及根据设计文档生成的软件设计模型,将上述两种模型输入至验证器Design Verifier进行验证,以判断软件设计模型是否符合安全规约模型,即软件设计模型是否符合软件需求规范,通过本步骤完成待开发软件的安全性验证,为软件的安全性验证提供了更规范的约束条件,克服了人为干扰因素大的问题,保证了软件的安全性。在本申请实施例中,验证器采用Provel SL引擎的形式化验证器Design Verifier。
基于步骤S110中获取到的软件需求规范,步骤S120根据预制定转换规则和MBD的软件规范符号进行匹配,形成安全规约模型。在图4中,模型输入为待验证的软件变量,输出为对软件变量验证的结果,结果为bool类型。
可选地,步骤S130中所涉及的SCADE软件设计模型,具体生成方法包括:
以设计文档作为输入,基于SCADE完成待开发软件的设计实现,输出软件设计模型。
在一个可能的实施方式中,以起落架控制器为例进行软件验证,基于上述起落架控制结构原理,本实施例将本实施例根据软件设计模型将功能封装成了三个主要模块,参见图5,模块包括:同步模块(Sys)、指令执行模块(CommandLine)和健康监控模块(Monitoring),Sys模块实现了将飞机三点处的起落架状态信息进行同步,防止起落架不同步导致的飞机失控。CommandLine模块功能是处理起落架的状态信息,并根据信息和控制指令输出对起落架中电子阀门的控制,通过SCADE中提供的状态机描述了起落架的控制逻辑。Monitoring模块的功能实现对起落架状态的监控,防止起落架出现异常控制。
可选地,参见图6,步骤S130中SCADE软件的安全性验证包括如下步骤:
通过形式化验证器完成软件的验证,若验证通过,则软件设计模型符合软件安全需求,否则输出用于修改SCADE软件设计模型的反例。
具体地,基于步骤S110中具体涉及的FTA建立起落架控制系统的故障树模型,并通过步骤S120将故障树模型按照预制定的转换规则形成安全规约模型,最后将安全规约模型和SCADE中的设计模型作为输入,利用SCADE中的形式化验证器Design Verifier对软件进行形式化验证,如果验证通过,则表明软件设计模型中不存在不符合软件安全需求规范的异常行为;如果验证未通过,则给出反例,工程师根据反例可修改软件设计模型,修复软件缺陷。此处所指的反例由验证器自动生成,并且还伴随反例生成反例的路径信息,以便于错误分析和定位,提高了验证效率,方便开发人员进行修正。
SCADE软件设计模型为上述SCADE软件设计模型具体生成方法针对于待开发软件生成的软件设计模型,在本实施例中具体以起落架控制软件为例,针对于飞机上的不同待开发软件的安全性验证,SCADE软件设计模型应根据具体待开发软件做出适应性修改,在此不再赘述。
在一个实施例中,提供了一种安全关键软件验证装置20,如图7所示,包括:
规范生成模块201,用于基于LTL语言扩展FTA模型得到形式化的系统安全性约束条件及对应的软件需求规范;
模型转换模块202,用于将所述软件需求规范和MBD软件规范软件模范符号匹配,使所述软件需求规范转化为安全规约模型;
验证模块203,用于将所述安全规约模型和完成预验证的SCADE软件设计模型输入模型验证器,完成对软件的安全性验证。
可选地,所述规范生成模块201,具体用于:
获取FTA的最小割集X,并确定FTA中顶事件T和最小割集X之间的关系;
获取针对于顶事件T和最小割集X的故障树的安全性约束条件及与所述安全性约束条件对应的软件需求规范。
可选地,所述规范生成模块201中所述顶事件T关于所述最小割集X的关系表达式为
其中,式中∑代表并集,II代表交集,Xi代表第i个最小割集,Xi表示第i个最小割集,Cj表示第j个中间事件,r表示中间事件的个数。
可选地,所述模型转换模块202中,所述软件需求规范与安全规约模型的预制定转换规则为
其中,“\”表示没有对应的形式化建模符号。
可选地,所述验证模块203中所述SCADE软件设计模型的生成方法,包括:
以设计文档作为输入,基于SCADE完成待开发软件的设计实现,输出软件设计模型。
可选地,所述验证模块203,具体用于:
通过形式化验证器完成软件的验证,若验证通过,则软件设计模型符合软件安全需求,否则输出用于修改SCADE软件设计模型的反例。
本申请实施例提供的安全关键软件验证装置20与上述安全关键软件验证方法采用了相同的发明构思,能够取得相同的有益效果,在此不再赘述。
基于与上述安全关键软件验证方法相同的发明构思,本申请实施例还提供了一种电子设备30,如图8所示,该电子设备30可以包括处理器301和存储器302。
处理器301可以是通用处理器,例如中央处理器(CPU)、数字信号处理器(DigitalSignal Processor,DSP)、专用集成电路(Application Specific Integrated Circuit,ASIC)、现场可编程门阵列(Field Programmable Gate Array,FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件,可以实现或者执行本申请实施例中公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成,或者用处理器中的硬件及软件模块组合执行完成。
存储器302作为一种非易失性计算机可读存储介质,可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块。存储器可以包括至少一种类型的存储介质,例如可以包括闪存、硬盘、多媒体卡、卡型存储器、随机访问存储器(Random Access Memory,RAM)、静态随机访问存储器(Static Random Access Memory,SRAM)、可编程只读存储器(Programmable Read Only Memory,PROM)、只读存储器(Read Only Memory,ROM)、带电可擦除可编程只读存储器(Electrically Erasable Programmable Read-Only Memory,EEPROM)、磁性存储器、磁盘、光盘等等。存储器是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质,但不限于此。本申请实施例中的存储器302还可以是电路或者其它任意能够实现存储功能的装置,用于存储程序指令和/或数据。
本领域普通技术人员可以理解:实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成,前述的程序可以存储于一计算机可读取存储介质中,该程序在执行时,执行包括上述方法实施例的步骤;上述计算机存储介质可以是计算机能够存取的任何可用介质或数据存储设备,包括但不限于:移动存储设备、随机存取存储器(RAM,Random Access Memory)、磁性存储器(例如软盘、硬盘、磁带、磁光盘(MO)等)、光学存储器(例如CD、DVD、BD、HVD等)、以及半导体存储器(例如ROM、EPROM、EEPROM、非易失性存储器(NAND FLASH)、固态硬盘(SSD))等各种可以存储程序代码的介质。
或者,本申请上述集成的单元如果以软件功能模块的形式实现并作为独立的产品销售或使用时,也可以存储在一个计算机可读取存储介质中。基于这样的理解,本申请实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)执行本申请各个实施例所述方法的全部或部分。而前述的存储介质包括:移动存储设备、随机存取存储器(RAM,Random Access Memory)、磁性存储器(例如软盘、硬盘、磁带、磁光盘(MO)等)、光学存储器(例如CD、DVD、BD、HVD等)、以及半导体存储器(例如ROM、EPROM、EEPROM、非易失性存储器(NAND FLASH)、固态硬盘(SSD))等各种可以存储程序代码的介质。
Claims (10)
1.一种安全关键软件验证方法,其特征在于,包括:
基于LTL语言扩展FTA模型得到形式化的系统安全性约束条件及对应的软件需求规范;
将所述软件需求规范按照预制定转换规则和MBD的软件规范符号匹配,使所述软件需求规范转化为安全规约模型;
将所述安全规约模型和预先生成的SCADE软件设计模型输入模型验证器,完成对软件的安全性验证。
2.根据权利要求1所述的方法,其特征在于,所述基于LTL语言扩展FTA得到规范化的系统安全性约束条件及对应的软件需求规范,包括:
获取FTA的最小割集X,并确定FTA中顶事件T和最小割集X之间的关系;
获取针对于顶事件T和最小割集X的故障树的安全性约束条件及与所述安全性约束条件对应的软件需求规范。
6.根据权利要求1所述的验证方法,其特征在于,所述SCADE软件设计模型的生成方法,包括:
以设计文档作为输入,基于SCADE完成待开发软件的设计实现,输出软件设计模型。
7.根据权利要求1所述的验证方法,其特征在于,所述SCADE软件的安全性验证包括如下步骤:
通过形式化验证器完成软件的验证,若验证通过,则软件设计模型符合软件安全需求,否则输出用于修改SCADE软件设计模型的反例。
8.一种安全关键软件验证装置,其特征在于,包括:
规范生成模块,用于基于LTL语言扩展FTA得到形式化的系统安全性约束条件及对应的软件需求规范;
模型转换模块,用于将所述软件需求规范和MBD软件规范软件模范符号匹配,使所述软件需求规范转化为安全规约模型;
验证模块,用于将所述安全规约模型和完成预验证的SCADE软件设计模型输入模型验证器,完成对软件的安全性验证。
9.一种电子设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,其特征在于,所述处理器执行所述计算机程序时实现权利要求1至7任一项所述方法的步骤。
10.一种计算机可读存储介质,其上存储有计算机程序指令,其特征在于,该计算机程序指令被处理器执行时实现权利要求1至7任一项所述方法的步骤。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202210031298.7A CN114385501A (zh) | 2022-01-12 | 2022-01-12 | 一种安全关键软件验证方法、装置、设备及介质 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202210031298.7A CN114385501A (zh) | 2022-01-12 | 2022-01-12 | 一种安全关键软件验证方法、装置、设备及介质 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN114385501A true CN114385501A (zh) | 2022-04-22 |
Family
ID=81201975
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202210031298.7A Pending CN114385501A (zh) | 2022-01-12 | 2022-01-12 | 一种安全关键软件验证方法、装置、设备及介质 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN114385501A (zh) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN114995809A (zh) * | 2022-07-21 | 2022-09-02 | 军事科学院系统工程研究院网络信息研究所 | 一种可证明的高安全软件构造方法及系统 |
CN116755662A (zh) * | 2023-08-18 | 2023-09-15 | 深圳海云安网络安全技术有限公司 | 一种应用开发安全需求的生成方法及系统 |
-
2022
- 2022-01-12 CN CN202210031298.7A patent/CN114385501A/zh active Pending
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN114995809A (zh) * | 2022-07-21 | 2022-09-02 | 军事科学院系统工程研究院网络信息研究所 | 一种可证明的高安全软件构造方法及系统 |
CN114995809B (zh) * | 2022-07-21 | 2022-09-30 | 军事科学院系统工程研究院网络信息研究所 | 一种可证明的高安全软件构造方法及系统 |
CN116755662A (zh) * | 2023-08-18 | 2023-09-15 | 深圳海云安网络安全技术有限公司 | 一种应用开发安全需求的生成方法及系统 |
CN116755662B (zh) * | 2023-08-18 | 2023-10-20 | 深圳海云安网络安全技术有限公司 | 一种应用开发安全需求的生成方法及系统 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
Abdulla et al. | Designing safe, reliable systems using scade | |
Atlee et al. | State-based model checking of event-driven system requirements | |
CN114385501A (zh) | 一种安全关键软件验证方法、装置、设备及介质 | |
Liggesmeyer et al. | Improving system reliability with automatic fault tree generation | |
Pakonen et al. | Model checking reveals design issues leading to spurious actuation of nuclear instrumentation and control systems | |
Lopatkin et al. | Patterns for representing FMEA in formal specification of control systems | |
Tarasyuk et al. | Integrating stochastic reasoning into Event-B development | |
Prokhorova et al. | Facilitating construction of safety cases from formal models in Event-B | |
Alrajeh et al. | Automated support for diagnosis and repair | |
Garrett et al. | Context in the risk assessment of digital systems | |
Bozzano et al. | Formal Methods for Aerospace Systems: Achievements and Challenges | |
CN114153422A (zh) | 一种基于形式化模型的智能合约代码设计生成方法及系统 | |
Bassan et al. | Formally Explaining Neural Networks within Reactive Systems | |
Rauzy et al. | Model-based safety assessment: Rational and trends | |
Preschern et al. | Catalog of safety tactics in the light of the IEC 61508 safety lifecycle | |
Lahtinen | Hardware failure modelling methodology for model checking | |
Fabarisov et al. | Model-based stochastic error propagation analysis for cyber-physical systems | |
Oveisi et al. | A new approach to promote safety in the software life cycle | |
Hagihara et al. | Minimal strongly unsatisfiable subsets of reactive system specifications | |
Mutzke et al. | Model-based analysis of timing errors for reliable design of mechatronic medical devices | |
Zhang et al. | Assume-guarantee reasoning framework for MDP-POMDP | |
Medikonda et al. | An approach to modeling software safety in safety-critical systems | |
Simmons et al. | Automating model checking for autonomous systems | |
Andrews et al. | Selective regression testing of safety-critical systems: a black box approach | |
Jharko | Formalizing the Safety Functions to Assure the Software Quality of NPP Safety Important Systems. |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination |