基于需求的IMA安全验证分析方法与流程

文档序号:11199837阅读:509来源:国知局
基于需求的IMA安全验证分析方法与流程

本发明涉及一种安全验证分析方法,特别是一种基于需求的ima安全验证分析方法。



背景技术:

综合模块化航空电子(ima)是航电系统架构发展新的阶段,ima架构给航电开发带来了更多的灵活性,显著地提升了开发效率。ima架构一个重要益处就是允许应用系统独立地开发,然后集成到统一的ima平台之上共享硬件资源。系统开发与安全性评估的隔离,加上不同开发人员对于系统安全性认知的不同使得ima的安全性分析变得十分复杂。传统的基于事件链模型的危害分析方法将硬件与软件放在一起考虑且主要考虑组件失效,这些传统危害分析方法适用于联合式航电系统,并不适用于ima这种软件密集型系统。相比于组件失效,ima中存在大量潜在的危害是由组件交互引起的,目前关于ima系统安全性的分析与验证的研究较少,且还没有很好地解决这方面的问题。



技术实现要素:

本发明所要解决的技术问题是提供一种基于需求的ima安全验证分析方法,找到组件交互产生的潜在危害,得到系统的安全需求。

为解决上述技术问题,本发明所采用的技术方案是:

一种基于需求的ima安全验证分析方法,其特征在于包含以下步骤:

步骤一:确定系统级危害和安全约束;

步骤二:构建出系统的控制结构图,通过控制结构图找出不安全的控制行为,进而得到系统的安全需求;

步骤三:用scr模型对安全需求进行建模,对描述不准确的需求进行修改,并用形式化的方法验证需求的可靠性和准确性。

进一步地,所述步骤一具体为,从ima系统提供的服务出发,找到ima提供的与分区通信相关的服务,然后找到会导致相关服务失效的危险,确定分区通信的系统级危险,若ima的分区间通信服务失效,则会导致分区通信系统的系统级危险。

进一步地,所述分区通信的系统级危险包含,

h1通道没有正确获取发送进程发送的消息;

h2接收进程没有正确接收通道的消息;

h3分区通信初始化过程出现错误;

进而产生系统级的安全约束:

sc1通道必须要正确获取发送进程发送的消息;

sc2接收进程必须正确接收通道的消息;

sc3分区通信初始化过程不能出错。

进一步地,所述步骤二包含,

2.1熟悉系统,了解整个系统的工作方式和系统结构,找出系统的所有独立的组件,分析每个组件在系统中的作用,提取控制动作和反馈动作,构建出控制结构图;

2.2从控制结构图中提取控制动作,从“没有提供所需的安全控制行为”,“提供了不正确的控制行为”,“不正确的时间/顺序”,“停止过快/过慢”四类控制不力的情况出发,分析每个控制动作可能会导致的系统危险,得到不安全的控制行为,并根据不安全的控制动作得出安全约束;

2.3分析不安全控制行为产生原因,原因包含系统缺陷、组件失效、算法缺陷和外界环境干扰;

2.4把提取出的安全约束作为系统的安全需求,提取需求中的变量。

进一步地,所述2.1具体为,ima分区通信分为两个阶段:初始化阶段和通信阶段,针对两个不同阶段分别构建控制结构图,以提取不同阶段的安全需求;在构建通信阶段的控制结构图时,先构建通信阶段的流程图,然后在流程图中提取控制动作和反馈动作,找出控制方和被控制方,构建出通信阶段的控制结构图。

进一步地,所述2.2具体为,从控制结构图中提取控制动作得到分区通信模块14个控制动作,其中初始化阶段4个控制动作,通信阶段10个控制动作,按照stpa方法从“没有提供所需的安全控制行为”、“提供了不正确的控制行为”、“不正确的时间/顺序”、“停止过快/过慢”四类控制不力的情况出发,分析每个控制动作会导致的系统危险,得到不安全的控制行为,通过对14个控制动作的分析,得到70个uca,其中初始化阶段有16个uca,通信阶段有54个uca,识别出不安全控制行为可以转换为有关系统组件行为的安全约束,即得到系统的安全需求,通过对得到的70个uca的分析,得到分区通信的安全约束。

进一步地,所述步骤三包含,

3.1根据安全需求,构建变量之间的关系,建立scr模型,验证安全需求的描述准确性,对描述不准确的需求进行修改;

3.2把建立好的scr模型在t-vec工具上进行模拟,进行形式化验证,确保系统需求的可靠性和准确性。

进一步地,所述3.1具体为,提取完安全需求的变量之后,找到变量之间的关系,把安全需求用形式化的语言描述,对不明确的安全需求进行相应的修改完善,使stpa方法得到的安全需求表述更加准确,对形式化表述之后的安全需求构建scr关系表。

进一步地,所述3.2具体为,把构建好的scr模型在t-vec工具上进行模拟,进行形式化验证,确保系统需求各变量和需求间的依赖关系符合系统要求,且需求所描述的系统行为满足安全性,通过t-vec工具可以自动生成测试向量。

本发明与现有技术相比,具有以下优点和效果:

1、本发明利用stpa方法能有效分析系统的控制结构,找到组件交互产生的潜在危害,得到系统的安全需求。

2、本发明结合了安全需求分析方法和形式化模型,为安全关键系统需求的产生和验证提供了一种有效的方法流程。

3、本发明利用scr模型检对需求进行形式化验证,提高了需求描述的准确性,验证需求的一致性和完备性检查并为需求生成自动测试向量。

附图说明

图1是本发明的基于需求的ima安全验证分析方法的流程框图。

图2是本发明的实施例的分区通信模块安全性分析验证的初始化阶段的控制结构图。

图3是本发明的通信阶段的控制结构图。

图4是本发明的通过uca寻找安全缺陷的流程图。

图5是本发明的scr模型生成的自动测试向量示意图。

图6是本发明的表1示意图。

图7是本发明的表2示意图。

图8是本发明的表3示意图。

图9是本发明的表3示意图。

具体实施方式

下面结合附图并通过实施例对本发明作进一步的详细说明,以下实施例是对本发明的解释而本发明并不局限于以下实施例。

如图1所示,本发明的一种基于需求的ima安全验证分析方法,包含以下步骤:

步骤一:确定系统级危害和安全约束;分析系统级危害,获取分区通信模块的系统级安全性约束条件。为了找到能导致分区通信模块的系统级危险,从ima系统提供的服务出发,找到ima提供的与分区通信相关的服务,然后找到会导致相关服务失效的危险,这样就确定了分区通信的系统级危险。若ima的分区间通信服务失效,则会导致分区通信系统的系统级危险。通过对分区通信的研究,可以得到以下三个系统级危险(hazard):

h1通道没有正确获取发送进程发送的消息;

h2接收进程没有正确接收通道的消息;

h3分区通信初始化过程出现错误。

进而产生系统级的安全约束(safetyconstraint):

sc1通道必须要正确获取发送进程发送的消息;

sc2接收进程必须正确接收通道的消息;

sc3分区通信初始化过程不能出错。

安全性是一种涌现性,系统的安全性是由安全性约束条件来保障的。系统级危害的发生意味着系统级的安全性约束条件被违反。因此,除了确定系统级危害外,还需要确定系统级安全性性约束,以便在后续分析中确定安全性约束如何被满足。

步骤二:构建出系统的控制结构图,通过控制结构图找出不安全的控制行为,进而得到系统的安全需求;

步骤二包含,

2.1熟悉系统,了解整个系统的工作方式和系统结构,找出系统的所有独立的组件,分析每个组件在系统中的作用,提取控制动作和反馈动作,构建出控制结构图;

ima分区通信分为两个阶段:初始化阶段和通信阶段。初始化阶段和通信阶段的控制动作完全不一样,且对系统的安全性息息相关,所以本文针对两个不同阶段分别构建控制结构图,以便提取不同阶段的安全需求。在构建通信阶段的控制结构图时,考虑到通信的时序性,先构建了通信阶段的流程图,然后在流程图中提取控制动作和反馈动作,找出控制方和被控制方,构建出通信阶段的控制结构图。初始化阶段的控制结构图如图2,通信阶段的控制结构图如图3。

构建系统的分层控制结构可以清楚地表现表面系统不同层次的交互过程,以及各个层级之间的关系,为进一步辨识导致系统危险的原因(不安全控制)奠定分析基础。控制结构并不仅包含分层控制框图所体现的信息,还包含对各个控制过程所进行的描述,如过程模型、控制算法等。

2.2从控制结构图中提取控制动作,从“没有提供所需的安全控制行为”,“提供了不正确的控制行为”,“不正确的时间/顺序”,“停止过快/过慢”四类控制不力的情况出发,分析每个控制动作可能会导致的系统危险,得到不安全的控制行为,并根据不安全的控制动作得出安全约束;

从步骤2.1的控制结构图中,得到了分区通信模块14个控制动作(附录1)(ca,controlaction),其中初始化阶段4个控制动作,通信阶段10个控制动作。分区通信的控制行为可能导致系统级危险,按照stpa方法可从“没有提供所需的安全控制行为”,“提供了不正确的控制行为”,“不正确的时间/顺序”,“停止过快/过慢”四类控制不力的情况出发,分析每个控制动作可能会导致的系统危险,得到不安全的控制行为(uca,unsafecontrolaction)。通过对14个控制动作的分析,得到74个uca(附录2),其中初始化阶段有16个uca,通信阶段有54个uca。识别出不安全控制行为可以转换为有关系统组件行为的安全约束,即得到系统的安全需求,通过对上节得到的74个uca的分析,得到分区通信的安全约束(sc,safetyconstraint),一共有56个(附录3)。图6所示的表1给出通过控制动作识别出uca的过程。

上述四种不同类型的不安全控制行为确定每个控制器(包括人工控制器和自动控制器)潜在的不安全控制行为。这些通用分类仅作为不安全控制辨识时的参考,针对具体的系统需要具体区分。另外,由于危险分析的主要目的是在事故发生前找出潜在的危险原因并进行预防,因而需要根据辨识出的危险原因——不安全控制来形成具体的安全约束,以保证系统的安全。

2.3分析不安全控制行为产生原因,原因包含系统缺陷、组件失效、算法缺陷和外界环境干扰;针对2.2辨识出的不恰当控制行为,分析其控制缺陷。要分析不恰当控制行为的产生原因,可以依据stpa方法提供的一般控制模型所要考虑的因素出发,对不恰当控制行为进行分析,找出其中的控制缺陷,uca37分析控制缺陷的过程如图4。

分析不安全控制行为产生原因。这个阶段辨别控制结构中的控制缺陷(controlflaws)——导致危害发生的原因。stpa分析不仅要找到上述的不安全控制行为,还需要进一步分析产生这些不安全控制行为的原因,及控制缺陷,控制缺陷会和安全需求一同交付系统开发人员,使其在构建系统时能更好的是安全需求得到满足。

2.4把提取出的安全约束作为系统的安全需求,提取需求中的变量。对2.2提取的安全需求进行验证,首先提取安全需求中的变量,确定变量的类型和取值范围。如图7所示的表2给出了sc1-sc5的所有变量集合。

对安全需求提取变量,分析需求中的所有实体,把每个实体对应scr模型的中不同变量类型。

步骤三:用scr模型对安全需求进行建模,对描述不准确的需求进行修改,并用形式化的方法验证需求的可靠性和准确性。

步骤三包含,

3.1根据安全需求,构建变量之间的关系,建立scr模型,验证安全需求的描述准确性,对描述不准确的需求进行修改;

提取完安全需求的变量之后,需要找到变量之间的关系,把安全需求用形式化的语言描述,sc1-5的形式化描述如图4。对不明确的安全需求进行了相应的修改完善,使stpa方法得到的安全需求表述更加准确。如图8和图9所示的表3和表4所示,对形式化表述之后的安全需求构建scr关系表。

变量之间的关系包括四种结构,利用这四种结构可以以一种更加实际和简明的方式对系统进行描述,这四种结构分别是模式(mode),项(term),条件(condition)和事件(event)。其中,模式类是定义在受监控的变量上的状态机,状态机中的状态称为系统模式(或简单的称之为模式),其中的状态转换由事件触发,复杂系统可同时定义多个模型类,这些模式类可以一种并行方式进行操作。项定义在输入变量、模式或其他项上,用以描述系统中的某个场景。条件即为断言,定义在系统中一个或多个实体之上(一个系统实体是指一个输入或输出变量,模式或项)。由事件来改变系统实体的值,所有事件中有一种特殊的事件,称为输入事件,当输入变量值发生变化时会触发该类事件,同时,当有一个特定条件为真时,如果事件发生,则称该事件为条件事件。下面给出相关定义:

定义1系统状态是关于rf中的各个实体名到具体值之间映射的函数,更详细来讲,对所有的r∈rf:s(r)=v,v=ty(r)。因此,通过假设,系统中任何一个状态s,都是模式类中的某一模式,且每个实体都拥有唯一值。

—ms是n个非空且两两不相交的集合相结合构成,即m1,m2,...,mn,称为模式类。模式类中每个成员都称为模式。

—ts是数据类型集,每个类型是值的一个非空集。

—vs=ms∪ts,是实体值集。

—rf是实体名集合。rf又分为四个子集:ms,模式类的名称集;ir,输入变量的名称集;or,输出变量的名称集;gr,项的名称集。对于所有的是实体名r的类型(也就是可能的值集),对所有的r∈mr,存在i满足ty(r)=mi,那么称r为对应于mi的模式类名。

定义2条件是通过逻辑连接符∪,∩和将简单条件连接组成的逻辑语句。

条件定义在rf的实体值上,简单条件可以是true,false,或一条逻辑语句其中r∈rf是一个实体名,是关系操作符,v∈ty(r)是常量值。

定义3事件定义如下:

@t(c)when

其中,条件c中的状态是原始状态,而条件c,中的状态是改变后的新的状态。给定那么可将c,定义为基于这些定义以及标准谓词演算规则,任何一个条件事件都可以表示为一个逻辑语句。

定义4系统是一个四元组,{em,s,s0,t},其中:

—em是输入事件集合,

—s是可能的系统状态集,

—s0是一个特殊的状态集,称为初始状态,

—t是系统转换。

3.2把建立好的scr模型在t-vec工具上进行模拟,进行形式化验证,确保系统需求的可靠性和准确性。

把构建好的scr模型在t-vec工具上进行模拟,进行形式化验证,确保系统需求各变量和需求间的依赖关系符合系统要求,且需求所描述的系统行为满足安全性,通过t-vec工具可以自动生成测试向量,t-vec生成的测试报告如图5所示。

把构建好的scr模型模拟,进行形式化验证,确保系统需求各变量和需求间的依赖关系符合系统要求,且需求所描述的系统行为满足安全性,自动生成测试向量。

本说明书中所描述的以上内容仅仅是对本发明所作的举例说明。本发明所属技术领域的技术人员可以对所描述的具体实施例做各种修改或补充或采用类似的方式替代,只要不偏离本发明说明书的内容或者超越本权利要求书所定义的范围,均应属于本发明的保护范围。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1