CN103853871B - 一种适用于航电***的安全需求建模方法 - Google Patents

Abstract

本发明公开了一种适用于航电***的安全需求建模方法，该方法通过对航空嵌入式***的安全性相关的概念和约束进行分析提取，并将提取的概念和约束与RUCM中的基本概念相结合，实现对UCMeta的扩展从而建立安全性相关的领域模型；通过对建立的领域模型进行分析，确定出航空嵌入式***安全需求的描述模板使其在准确描述功能需求的同时又捕获安全性相关的非功能约束。本发明方法是一种半形式化的安全性需求描述方法，在RUCM的基础上增加安全性需求的描述模板和相应的限制规则，用于完整的、准确的对安全性需求进行描述，并支持一定程度的自动化验证。

Description

一种适用于航电***的安全需求建模方法

技术领域

本发明涉及一种需求建模的方法，更特别地说，是指一种适用于航电***的安全需求建模方法。

背景技术

软件安全性（software safety）是关于软件所控制的***始终处于不危及人的生命财产和生态环境的安全状态的一种性质。尤其是对于航空航天等需要高安全性的嵌入式实时软件而言，随着***中软件所占比重的逐步增大，软件失效可能引起的后果也越来越严重。为保证***的安全性，需要在需求分析阶段对***的安全性进行描述和分析。

需求建模是软件需求工程中的一项重要的活动，需求工程师通过采用不同的建模方法识别、理解、挖掘需求提供者对***的期望，从而构建软件***的结构模型，行为模型，或者其他各种对展示待开发软件的不同特性的模型。建模方法在这个活动中占了重要的作用，采用不同的建模方法意味着从不同的视角去看待软件问题，如何从对整体***的期望中推导出对软件***本身的期望，去展示软件***如何行为并在软件加强型***中如何起到它的作用。参见2008年7月第一版《软件需求工程：原理与方法》第50页，金芝等编著。

在目前的需求建模方法中，主要使用的描述手段和技术是自然语言、图形符号语言和形式语言等。从实用性角度来划分有：结构化的需求建模方法和面向对象的需求建模方法。

面向对象方法的技术路线包括有需求工程、软件设计和软件实现；其中，需求工程有需求获取和需求分析。面向对象方法首先从需求的源头（主要是用户）进行需求的获取，组织需求信息的用户描述，建立用例模型。在得到用户需求的完整、准确理解之后，面向对象方法就开始考虑软件的实现机制，进行软件设计。2009年4月第1版《需求工程－软件建模与分析》第315页，骆斌主编。

综合模块化航空电子***（Integrated Modular Architecture，IMA，简称航电***）的软件包括操作***、应用程序、数据库、网络、人机界面等应遵循统一的系列标准、规范研制开发，软件的可重用、标准化、智能化、可移植性、质量、可靠性等都应列入表征软件技术的特征参数之中。

发明内容

为了使所需构建的航电***软件具有较高的安全性需求，本发明提供一种适用于航电***的安全需求建模方法。本发明的建模方法应用RUCM中的用例元模型UCMeta对参与者Actor和用例Use Case进行安全扩展，实现所需构建的航电***软件的需求建模的描述；引述DO－178B标准与现有航电***软件进行安全缺陷识别；通过本发明设计的安全需求模型能够为航电***的软件设计提供完整无二义的需求描述。

本发明的一种适用于航电***的安全需求建模方法，具体地有下列步骤：

步骤一：建立安全需求的领域概念模型；

依据RTCA/DO－178B标准对现有航电***软件进行安全识别创建得到领域概念模型；

步骤二：构建基于UCMeta元模型的航电***的图形扩展；该航电***的图形扩展是依据步骤一得到的安全需求的领域概念模型对UCMeta元模型进行扩展而得到；

步骤三：构建基于RUCM描述模板的航电***安全需求模板；该航电***安全需求模板是在RUCM描述模板上进行添加相关项得到。

在本发明中步骤二中，将领域概念模型转换为UML Profile，对RUCM的元模型UCMeta中进行安全扩展；在Actor中进行细化，对Use Case进行安全性扩展建立Safety UseCase；分析领域概念模型，确定出安全需求的描述模板以及限制规则和关键字的使用；扩展RUCM描述模板进行安全需求描述，添加10条安全描述规则和若干关键字以保证RUCM的描述完整、准确、无二义性；扩展后的UCMeta创建支持安全需求描述的Use Case Diagram，同时用户通过每一个Use Case都进行了完整准确的功能描述和安全需求描述。

本发明安全需求建模方法的优点在于：

①本发明针对高安全性的航空嵌入式***，对安全标准DO-178B进行了深入学习并创建了相应的安全模型，从而可以在软件需求阶段对安全需求进行建模。

②本发明针对航空嵌入式***的安全需求建模，扩展了标准RUCM的UCMeta。UCMeta是RUCM方法的元模型，它是使用MOF（Meta Object Facility）定义的。通过领域分析对UML标准Use Case Diagram中的模型元素Actor和Use Case进行细化和安全扩展从而可以支持进行图形化的安全需求建模。

③本发明针对航空嵌入式***的安全需求建模，扩展了标准RUCM的需求描述模板及其限制规则。通过扩展RUCM的需求描述模板可以支持在软件需求建模阶段对安全相关的故障处理进行描述，并通过限制规则的扩展使得安全需求的描述完整、准确、无二义性。

附图说明

图1是常规面向对象方法的技术路线图。

图2为本发明适用范围内的领域概念模型图。

图3为本发明所述的RUCM的UCMeta包图。

图4为本发明所述的UCSTemplate包图。

图5为本发明所述的Actor细化模型图。

图6为本发明所述的Use Case扩展模型图。

图7为本发明所述的Use Case与Actor或资源之间的数据交换图。

图8为本发明所述的失效模型图。

图9为本发明所述的失效处理分析模型图。

图10为本发明所述的失效处理语句模型图。

图11为Use case template需求的各栏信息示意图。

具体实施方式

下面将结合附图和实施例对本发明做进一步的详细说明。

参见图1所示，图1中的“用例模型”就是本发明申请中需要建模得到的安全需求模型。

本发明的一种适用于航电***的安全需求建模方法，具体包括有下列步骤：

步骤一：建立安全需求的领域概念模型

依据RTCA/DO－178B标准对现有航电***软件进行安全识别创建得到领域概念模型。

RTCA/DO－178B标准的全称是Royal Technical Commision on Aviation DO-178B。

安全需求是由安全级别的要求和安全功能的要求两个部分组成的。安全级别的要求主要为安全隔离措施，即不同安全等级的软件需要给予不同程度的关注；安全功能的要求主要包括对***中引发危害状态的失效进行识别，降低其进入不安全状态的概率和削弱其危害后果。

危害（Hazard）指由功能失效或外部事件等造成的***潜在的不安全状态，DO－178B标准中对危害的级别进行了划分，表明其对***的影响，这些类别分别是：灾难性的、危险的/严重的、较重的、较轻的、无影响的；相应的对安全关键软件定义其安全级别，根据其引发的危害的严重程度进行划分，同样分为5个级别。

表1：软件安全级别

安全功能需求即对***中可能引发的危害进行识别，并采取一定的措施降低其发生概率或减轻其影响的要求。从下面几个角度对安全功能进行划分：

1）失效模式和失效影响分析

失效模式指失效发生的方式。通过对GB7826标准和GJBZ1391标准的学习，本发明中将失效模式分为五类：输入数据失效、输出数据失效、无法完成预期的功能失效、超时失效和异常的硬件、用户或环境造成的失效。

用失效影响来表示用例（Use Case）的失效对该用例所在的***或子***造成的影响，而当该影响会对***产生一定的危害（对安全性造成影响）时，该用例为安全关键的。

表2：失效的定义

英文	中文意义
		FailureID	失效的唯一标识
FailureDescription	失效的描述
		Failure Mode	失效模式
Failure Cause	失效原因
		Level	失效的安全级别
Hazard	失效引起的危害

对于每个危害（Hazard），定义其严重程度和发生的概率，严重程度和发生概率均为定性分析。在***需求分析阶段可能无法确定或者很难确定一个危害的发生概率，可以先用None表示，数据完整时再对其进行补充。危害的风险为其发生概率和严重程度的组合，根据风险分析可对危害进行分类。失效的严重程度是根据其可能导致的风险程度最高的危害决定的。

表3：危害的定义

英文	中文意义
		Severity	危害的严重程度
Probability	危害的发生概率
		Failure	引发该危害的失效

危害可以分为两种：Single Failure Hazard和Combine Failure Hazard，即单个失效引起的危害和多个失效引起的危害。例如，飞机中可能有多套刹车***，则单个刹车***的失效不会对飞机造成危害，只有所有的刹车***全部失效才会导致 无法减速，对飞机造成危害，这种情况为多个失效引起的危害。而对于进程级健康监控，如其无法对故障进行处理则可能直接造成***危害，为单个失效引起的危害。

2）失效原因分析

通过故障分析来描述失效的原因，每个故障都有自己的触发条件，用Tigger来表示故障的触发。在一条或多条语句的执行过程成，对守护条件进行检查，如果条件不满足，则触发一个故障，进而导致用例失效。

对守护条件的描述是由安全约束（Safety Constraint）表示的。安全约束共分为三类：实时性约束、数据约束和状态约束。实时性约束为周期性或者执行时间的约束；数据约束主要为对数据值的约束，而状态约束则为对用例语句执行状态的约束，状态共分为三类：正常、异常终止、死循环。

表4：安全约束的定义

英文	中文意义
		ConstraintID	约束的标识
Sentence	字段中定义约束的有效范围
		Constraint	字段为约束的内容

在领域概念模型如图2所示中，本发明通过遵循DO-178B/C标准定义了12中安全属性，它们的具体的含义如下：

P1：每个安全构件都要提供相应的安全接口以检测并处理构件内部产生的故障和从外部传递过来的故障。

P2：与安全性相关的接口只能被安全构件或故障注册构件被激活。

P3：每个安全构件和它的安全接口必须要有相同的安全性级别。

P4：每个提供共享数据访问的安全构件都使用不变式来确保对数据的修改满足相应的约束。

P5：每个平台构件应该能够为相应的部署构件提供足够的资源。

P6：每个被识别的故障必须要至少被一个构件检测并处理。

P7：每个被识别的故障必须要有相应的激励和处理策略。

P8：每个能够传播的故障必须要能够被其他的安全构件处理。

P9：故障只能被安全通道注册到故障注册构件中。

P10：注册的故障只能被注册构件依据相应的处理策略进行处理。

P11：每个安全通道都要提供接口以保护安全构件之间交互的安全性。

P12：每个安全通道的安全级别不能比跟它连接的那些构件的安全级别低。

步骤二：构建基于UCMeta元模型的航电***的图形扩展

参见图2所示，在本发明中，依据步骤一得到的安全需求的领域概念模型对UCMeta元模型进行扩展，从而得到航电***的图形扩展。

UCMeta是RUCM方法的元模型，它是使用MOF（Meta Object Facility）定义的，包括有UCMeta、UML::UseCases、UCSTemplate、SentenceSemantics、SentencePatterns、SentenceStructure。其中后三者主要完成了对自然语言的规范限定。UCMeta的结构如图3所示。

对UCMeta的安全扩展重点关注UCSTemplate包，元类UseCase可通过添加到UseCaseSpecification的关系进行扩展。参见图4所示，UseCaseSpecification包含一个BriefDescription、Preconditon、一个或多个FlowOfEvents、一个primary actor、0到多个secondary actors。BriefDescription、Preconditon、PostConditon和FlowOfEvents均含有一系列的Sentences。有两种事件流：BasicFlow和AlternativeFlow。每个用例必须含有一个BasicFlow，可以有0到多个AlternativeFlow。每个事件流有一个PostCondition，由一系列的Sentences组成。有三种不同方式的分支流：GlobalAlternative，SpecificAlternative，和BoundedAlternative。每一个AlternativeFlow都有一个condition，对应一个引用流。

UCSTemplate中的语句分为三种：简单语句（元类SimpleSentence)，复杂语句（子包ComplexSentence)，特殊语句（子包SpecialSentence)。简单语句为含有一个独立分句没有从属子句：只有一个主语和一个谓语。UCMeta有四种复杂语句，对于四种关键词：条件(IF-THEN-ELSEELSEIF-THEN-ENDIF)、循环(DO-UNTIL)、并发(MEANWHILE)和验证(VALIDATES THAT)。有四种特定语句说明一个用例中的事件流是怎样与另外的事件流交互的，这四种分别对应四个关键字：RESUME STEP、ABORT、INCLUDE USE CASE和EXTENDED BY。

下面分别从活动者（Actor）、用例（Use Case）介绍本发明的详细扩展：

（A）活动者Actor的细化

UML中使用活动者来描述***外部与***发生交互的角色，通常可以是使用***的人员，也可以是外部设备或逻辑上的实体。UML标准并未对活动者进行分类。在RUCM中针对每个用例，将活动者分为主要活动者（Primary Actor）和次要活动者（SecondaryActor）。主要活动者是初始化该用例的第一个活动者，其余则是次要活动者。

本发明中将UML活动者的概念分类为四种类型，如图5所示，具体的内容如下：

（1）Timer，周期性产生特定事件的实体，拥有一个类型为NFP_Duration类型的duration（时长）属性。NFP_Duration是从UML/MARTE中导入的数据类型，包含一个实数和一个时间单位信息。

（2）HumanActor，表示该活动者是实际人员。

（3）ExternalInstrument，表示外部器件，其direction属性描述了该器件的数据输入输出方向，其signal属性描述了该器件的信号类型是数字信号或模拟信号。Sensor（传感器）和Actuator（作动器）是航电***领域的常用概念，在此作为ExternalInstrument的子类出现。

（4）ExternalSystem，用来描述外部***。

（B）Use Case的安全扩展

Use Case描述了***所执行的一组动作，通过与活动者的交互描述***行为，是重要的概念。RUCM方法中对Use Case的规格说明进行了规范。本发明中将Uase Case扩展为Safety Use Case，定义为实现一定安全功能的用例，而安全功能则表示对***或其组成部分的失效进行识别和处理的功能，因此，每一个Safety Use Case须关联到一个或多个失效的识别和处理。下面具体的介绍相关的扩展内容：

（1）Use Case的细化。本发明中Safety Use Case继承自Use Case，其模型如图5所示。将Safety Use Case定义为实现一定安全功能的用例，每一个Safety Use Case都有自己的安全级别它能够识别出相应的失效故障，每一个Safety Use Case须关联到一个或多个失效的识别和处理。

DO-178B标准中对安全级别进行定义和划分。Safety Use Case的安全性级别是根据其可能发生的失效的严重程度来确定的。安全级别分为五个等级，分别为level-A到level-E，分别对应灾难性的、危险的/严重的、较重的、较轻的、无影响的。对于不同级别Safety Use Case应给与不同程度的关注。

（2）软件安全级别的需求建模。对软件安全级别相关的需求和约束，即安全隔离措施进行定义。安全隔离措施指将安全关键***和非安全性关键***进行隔离，安全级别较高的***和安全级别较低的***进行隔离，以确保非安全性关键***或安全级别较低的***以预期外的方式影响到安全关键模块的功能。

本发明中对软件安全级别相关的需求和约束，即安全隔离措施进行了定义，具体表现可以分为两个方面：

a）当外部***或外部设备类型的Actor和Safety Use Case进行数据交换时，外部***或外部设备的安全级别应不低于Safety Use Case的安全级别。若为外部***，则应确保外部***的安全性；若为外部设备，则应选用较可靠的外部设备。

b）当Safety Use Case使用***中某一资源时，该资源的安全级别应不低于Safety Use Case的安全级别。

在本发明中用Communication Sentence来表示用例与执行者或者用例与资源之间的数据交换，如图6所示，Communication Media则是通讯介质，为数据的传输提供支持。模型中列举出了几种常见的通讯介质：system_call（***调用）、hw_port（硬件端口）、bus_protocol（总线）、lan_protocol（局域网）和sys_service（***提供的服务，如黑板、信号量以及缓冲区等）。

同样Resource也定义了相应的安全级别属性，用例可以通过一定的介质与资源、外部设备或者外部***进行数据交换。用关键字COLLECT INPUT FROM和关键字DELIEVROUTPUT TO表示从外部设备、外部***或其他用例收集或发送数据，用关键字VIA表示数据的传输方式。

（3）软件安全功能的需求建模。安全功能需求为对***中可能引发的危害进行识别，并采取一定的措施降低其发生概率或减轻其影响的要求。下面从三方面进行详细的介绍：

a）失效模式和失效影响分析，模型如图7所示，本发明中用失效影响来表示用例的失效对该用例所在的***或子***造成的影响，而当该影响会对***产生一定的危害（对安全性造成影响）时，该用例为安全关键的。所以，对于Safety Use Case，其失效一定会导致一个或多个危害Hazard。对于每个Hazard，定义其严重程度和发生的概率，严重程度和发生概率均为定性分析。危害的风险为其发生概率和严重程度的组合，根据风险分析可对危害进行分类。失效的严重程度是根据其可能导致的风险程度最高的危害决定的，而SafetyUse Case的安全级别则是由其安全级别最高的失效决定的。

b）失效原因分析，模型如图8所示，本发明通过故障分析来描述失效的原因，模型中列出了几种常见的故障类型。用Tigger来表示故障的触发，在一条或多条语句的执行过程成，对守护条件进行检查，如果条件不满足，则触发一个故障，进而导致用例失效。对守护条件的描述是由Safety Constraint（安全约束）表示的。安全约束共分为三类：实时性约束、数据约束和状态约束。实时性约束为周期性或者执行时间的约束；数据约束主要为对数据值的约束，而状态约束则为对用例语句执行状态的约束，状态共分为三类：正常、异常终止、死循环。用Safety Condition Sentence来描述条件检查语句。一个条件检查语句是对一条约束的检查。用关键字CHECK CONSTRAINT表示条件检查。如有约束语句c1，其作用范围为STEP1，约束为STATE=normal，则相应的条件检查语句示例如下：The system CHECKCONSTRAINT c1。

c）失效处理，图9中对失效的控制方式进行建模。采用一定的缓解措施对失效进行控制，Failure Mitigation定义为分支流的一种，可定义一系列的处理流程对失效进行处理。另外，对几种常用的失效处理方式进行建模。Record表示对失效进行记录；Retry表示重试失效部分功能，其属性retry_times定义重试的次数；Progogate表示在本用例中不对失效进行处理，而是将其交给其他用例或者***进行处理。同时可以根据失效的类型和原因，对每个失效定义一系列的处理流程。用几种特殊的语句表示失效的特殊处理方式，如所图10所示。其中，Record Sentence的使用形式为RECORD THE FAILURE；Retry Sentence的使用形式为RETRY FOR…TIMES；Propogate Sentence的使用形式为PROPOGATE TO USECASE…。

步骤三：构建基于RUCM描述模板的航电***安全需求模板

参见图11所示，RUCM描述模板的内容包括：用例名字（Use Case Nmae），用例简述（Brief Description），用例执行的前置条件（Precondition），用例的主要活动者（PrimaryActor），用例的其他活动者（Secondary Actors），该用例与其他用例的依赖关系（Dependency），该用例与其他用例之间的泛化关系（Generalization），该用例的基本事件流（Basic Flow）以及其他的三个事件流（Global Alternative Flow，BoundedAlternative Flow，Specific Alternative Flow）。其中每个事件流执行结束后都必须要有一个Post Condition表示该事件流执行后的结果，其中每一个用例中有且仅有一个Basic Flow，而Global Alternative Flow、Bounded Alternative Flow、SpecificAlternative Flow根据具体的实际情形确定其存在的个数。RUCM描述模板在使用时还配有相应的规则和关键字。

本发明中不仅对RUCM需求描述模板进行了安全需求描述的相关扩展，同时还增加了相应的新规则和关键字。下面分别从这两个方面进行详细的扩展：

（1）安全需求描述模板

标准的RUCM描述模板只定义了三种事件流，分别是基本事件流、全局扩展事件流和局部扩展事件流，为了进行安全需求的描述就必须要对事件流进行扩展以描述故障及其相应的处理方式。扩展事件流就是针对一个基本事件流或扩展事件流中某个或某些活动事件发生时的其他处理情况。

本发明中扩展后的安全需求描述模板如下：

表5：安全需求描述模板

表6：***危害表

Hazard	Severity	Probability	Failure

安全需求模板的基本部分和普通的RUCM用例模板基本保持一致，只添加一行SafetyLevel，对其安全级别进行描述。

在此基础上又添加安全性相关的概念描述，具体的扩展如下：

a）添加失效的描述

表7：失效描述

b）添加失效的降级处理描述

表8：失效的降级处理

Failure Mitigation：失效降级措施，为分支流，可定义一系列的处理流程对失效进行处理，也可以添加预定义的处理方式，每个Failure Mitigation都要有一个PostCondition以表示本次处理的结果。

c）添加约束定义

表9：约束定义

ConstraintID	Sentence	Constraint

Constraint部分是对用例中的约束进行定义，ConstraintID为约束的标记，Sentence字段中定义约束的有效范围，Constraint字段为约束的内容。

d）为整个***添加一个危害列表

表10：危害列表

Hazard	Severity	Probability	Failure

在进行了上述安全扩展后还需要对整个***维护一张危害列表，通过该列表可以对***中存在的各类危害，危害严重程度，危害发生概率以及引发危害的失效进行记录。Hazard表示具体的危害，Severity代表危害的严重程度，Probability代表该危害的发生概率，Failure表示引发该危害的失效。

在本发明中，有的英文没有指代中文意义的，可以是英文直接翻译成中文所表达的语意。

（2）为安全需求模板添加新的限制规则和关键字，

为了在易于表达和表达严谨性之间取得平衡，RUCM共设计了26条约束规则，其中16条规则用以约束自然语言的使用，10条规则用以定义10个带有控制结构的活动描述，但这些规则还不能满足软件安全性的相关描述。因此要对标准的RUCM规则进行扩展，本发明中有关安全需求描述的限制规则和关键字如下：

R1：当用例的执行者的类型为ExternalSystem或者ExternalInstrument时，ExternalSystem和ExternalInstrument的安全级别应不小于用例的安全级别。

R2：当用例访问某一资源时，该资源的安全级别应不小于用例的安全级别。

R3：用关键字COLLECT INPUT FROM和DELIEVR OUTPUT TO表示从其他用例或外部设备收集或发送数据，用关键字VIA表示数据通讯时使用的通讯介质。

R4：使用关键字AND表示多个失效共同引发一个危害。

R5：使用关键字>、<、=、IN表示约束值的范围，并且用关键字CHECK CONSTRAINT对约束进行检查。

R6：使用关键字RECORD THE FAILURE表示记录一个失效。

R7：使用关键字RETRY FOR..TIMES表示重试操作，可定义重试的次数。

R8：使用关键字PROPOGATE TO USE CASE表示失效的传播。

R9：当失效传播到另外一个用例进行处理时，该用例的安全级别应该不低于当前用例的安全级别。

R10：每个失效的安全级别由其引发的最严重的危害的严重程度决定，而每个用例的安全级别由其安全级别最高的失效决定。

实施例

下面的例子中使用安全需求模板及关键字对安全需求进行了描述。

Claims (2)

1.一种适用于航电***的安全需求建模方法，其包括有下列步骤：

步骤一：建立安全需求的领域概念模型；

依据RTCA/DO－178B标准对现有航电***软件进行安全识别创建得到领域概念模型；

步骤二：构建基于UCMeta元模型的航电***的图形扩展；该航电***的图形扩展是依据步骤一得到的安全需求的领域概念模型对UCMeta元模型进行扩展而得到；

步骤三：构建基于RUCM描述模板的航电***安全需求模板；该航电***安全需求模板是在RUCM描述模板上进行添加相关项得到；

在步骤二中，将领域概念模型转换为UML Profile，对RUCM的元模型UCMeta中进行安全扩展；在Actor中进行细化，对Use Case进行安全性扩展建立SafetyUse Case；分析领域概念模型，确定出安全需求的描述模板以及限制规则和关键字的使用；扩展RUCM描述模板进行安全需求描述，添加10条安全描述规则和若干关键字以保证RUCM的描述完整、准确、无二义性；扩展后的UCMeta创建支持安全需求描述的Use Case Diagram，同时用户通过每一个Use Case都进行了完整准确的功能描述和安全需求描述；

其特征在于：

在Actor中进行细化的步骤有：

步骤301：根据嵌入式实时***的特点对Actor进行扩展，将Actor划分为四种类型：Timer、Human Actor、External Instrument和External System；

步骤302：在嵌入式实时***中包含周期性的任务，而Timer则用来触发一个周期性的动作，其属性duration表示该周期的时间长度；其值的类型NFD_Duration包括时间的单位和时间值；Human Actor表示使用触发其相关用例的用户；

步骤303：External Instrument表示和用例进行数据交换的外部设备，即传感器或信号接收器；其属性direction和signal分别表示数据传输方向和信号类型；

步骤304：External System表示和用例进行交互的外部用例、子***或者***；

步骤305：External Instrument和External System均定义了安全级别；

所述的Use Case细化步骤有：

步骤401：Safety Use Case继承自Use Case；将Safety Use Case定义为实现安全功能的用例，而安全功能则表示对***或其组成部分的失效进行识别和处理的功能，因此，每一个Safety Use Case须关联到一个或多个失效的识别和处理；

步骤402：依据DO-178B标准中对安全级别进行定义和划分，Safety Use Case的安全性级别分为五个等级level-A到level-E，分别对应灾难性的、危险的/严重的、较重的、较轻的、无影响的；

所述的安全描述规则为：

R1：当用例的执行者的类型为ExternalSystem或者ExternalInstrument时，ExternalSystem和ExternalInstrument的安全级别应不小于用例的安全级别；

R2：当用例访问某一资源时，该资源的安全级别应不小于用例的安全级别；

R3：用关键字COLLECT INPUT FROM和DELIEVR OUTPUT TO表示从其他用例或外部设备收集或发送数据，用关键字VIA表示数据通讯时使用的通讯介质；

R4：使用关键字AND表示多个失效共同引发一个危害；

R5：使用关键字>、<、＝、IN表示约束值的范围，并且用关键字CHECKCONSTRAINT对约束进行检查；

R6：使用关键字RECORD THE FAILURE表示记录一个失效；

R7：使用关键字RETRY FOR TIMES表示重试操作的重试次数；

R8：使用关键字PROPOGATE TO USE CASE表示失效的传播；

R9：当失效传播到另外一个用例进行处理时，该用例的安全级别应该不低于当前用例的安全级别；

R10：每个失效的安全级别由其引发的最严重的危害的严重程度决定，而每个用例的安全级别由其安全级别最高的失效决定。

2.根据权利要求1所述的适用于航电***的安全需求建模方法，其特征在于航电***安全需求模板的完整结构为：

FailureID：每个失效的标识号；

FailureDescription：失效行为的简单描述；

Failure Mode：失效模式，其值为枚举类型；

Failure Cause：失效原因，为引发失效的故障的类型，其值为枚举类型；

Level：失效的安全级别，根据其导致的危害的严重程度确定；

Hazard：失效引发的危害名称；

FailureMitigate：失效减缓措施；

Constraint部分是对用例中的约束进行定义，ConstraintID为约束的标记，Sentence中定义约束的有效范围，constraint为约束的内容。