胡建成，胡 军，汪文轩，康介祥，王 辉，高忠杰

1(南京航空航天大学 计算机科学与技术学院，南京 211106)

2(软件新技术与产业化协同创新中心，南京 210007)

3(中国航空无线电电子研究所 软件部，上海 200233)

1 引 言

安全关键软件[1，2]是指应用于航空、航天、交通、能源等安全关键系统领域中的一类软件，此类软件系统要求具有高安全性、高可靠性和高健壮性等特征[3].近年来，随着安全关键系统的功能及复杂度的快速增长，以及软件很小的错误或者漏洞可能会导致非常严重的后果[4]，例如：财产的重大损失、环境的严重破坏或者是人员的重大伤亡等.因此，如何正确有效的开发此类系统软件成为了目前安全关键系统领域中的一个重要挑战.

从软件生命周期的角度来看，在一个软件产品开始的阶段定义并构造一个完整性、一致性良好的需求制品，是提高安全关键软件的产品质量和降低产品开发成本的最好方法之一.由于系统具备安全关键特征，相比较在设计或实现阶段引入的错误，在安全关键软件需求中存在的错误更可能会对这类系统的安全性产生重要影响.以航空电子系统(以下简称航电系统)中的软件系统为例，其相应的民用机载软件适航标准DO-178B/C[5]中就是以多层级需求为核心来展开航电软件研发的各类活动，并引入了最新的基于模型的系统/软件工程方法学以及形式化方法[6，7]来更好的支撑达成安全性等相关目标.

本文工作就是面向航空电子系统领域，展开从自然语言描述的条目化需求到形式化需求模型生成的方法研究，包括：分析航电领域的需求描述特征，从该领域的自然语言描述的条目化需求入手，设计定义一套面向领域的自然语言需求模板，并综合考虑所采用的形式化需求模型(VRM：Variable Relation Model)元素的语义，形成基于此模板的需求规范化方法；然后给出从规范化后的需求条目集到VRM模型的自动构造方法.最后选取了现代民机中综合电子显示系统中的典型功能子系统进行了实例需求建模及模型生成.

具体而言，本文后续内容安排如下：第2节是本文的相关技术背景介绍，如：机载软件适航认证标准DO-178B/C，基于模型的分析与验证方法等；第3节给出了基于自然语言需求的VRM建模框架的概要说明；在第4节中对研究框架中所涉及到的关键概念和技术点进行详细说明，包括领域概念库的语义定义、领域模板库的设计以及其组成元素的数学定义、VRM模型中各类表模型的自动构造算法等.第5节是对发动机指示和机组警告系统(EICAS)进行实例分析；最后一节是相关工作比较和总结.

2 相关技术背景

2.1 航空认证标准DO-178B/C

DO-178B/C《机载系统和设备合格审定中的软件考虑》标准是美国航空无线电委员会(RTCA)发布的民机软件系统开发的工业开发指南.其中以过程和目标为核心概念来给出航电软件研发中所关注的重点，尤其强调各层级需求(系统需求、软件高级需求、软件低级需求等)是航电软件研发中的重中之重.在最新的DO-178C标准中还专门增加了基于模型开发方法的支持(DO-331附件标准)[8]、面向对象(DO-332附件标准)[9]和形式化方法(DO-333附件标准)[10]，进一步引入了以需求为核心的双向追溯机制.

在DO-333中所引入的形式化方法是用于开发计算机硬件和软件系统的一类数学技术，通常分为模型检测、定理证明以及抽象解释等3大类方法.数学方法的严格性可以支持计算机系统研发项目生命周期中涉及到的不同层次上的模型分析.尤其是在需求与架构设计阶段，形式化方法可以用于准确的获取、解释和描述需求及其相应的约束.在本文工作中所应用的VRM模型是基于四变量模型[11]的核心语义，并面向航电软件进行领域化裁剪之后的形式化模型，其详细说明参见3.2小节.

2.2 基于模型的分析与验证

基于模型的系统/软件工程(Model Based System Engineering，MBSE)是通过建立多层级的建模与转换[12]，从系统/软件的概念设计阶段开始支持系统/软件需求、设计、分析、验证和确认等活动，并持续贯穿整个开发过程和后续的生命周期阶段.MBSE方法是从用户需求开始将系统逐层分解为各子系统、部件和模块等，并建立各类系统/软件的模型，最后进行各子系统和模块的实现，进行集成和验证，形成系统并进行确认，得到符合用户需求的系统产品.

一个完整项目的开发与实现，往往需要很多团队的合作共同去实现.通过MBSE方法框架，可以更好的进行技术活动的计划、组织、协调和控制，同时统筹各种资源的分配，有助于提高项目软件的生产效率，降低开发成本.本文工作的关注重点就是在需求层级，围绕如何从自然语言描述的需求建立有效的形式化需求模型进行展开.

3 面向领域自然语言需求的VRM建模

在本小节中首先给出了面向领域自然语言需求的形式化需求模型(VRM)的建模框架.包括在此框架中的自然语言需求模板化处理和从模板化需求到VRM形式化模型的自动构造两部分内容的总体说明.然后给出了本建模框架中形式化需求模型(VRM)的概要说明.

3.1 面向领域自然语言建模的框架

本文工作内容是属于一个总体项目ART(Avionics Requirement Tools)的研究内容的一部分(如图1所示).整个项目的目标是面向DO-178C标准，设计并实现一个满足标准中需求分析与验证要求的软件工具平台(ART).首先，在需求建模阶段，需要考虑现代民机航电软件需求中的领域特征，面向自然语言描述的航电领域需求条目，以“四变量理论模型”形式化方法为核心，给出一种构建包含条件、事件、模式、环境交互等要素的工程实用的形式化需求模型的建模方法(VRM).然后基于VRM的形式化语义，对需求模型展开一致性、完整性等性质的分析与验证.最后，经过形式化分析的VRM需求模型就可以用来自动生成测试用例集.

图1 航电软件需求工具ART

具体而言，本文工作内容重点就是针对高安全性的航电软件领域，提出一种面向领域自然语言需求的需求规范化方法，然后对规范化后的需求模型进行解析，提取其中包括条件、事件、模式等在内的核心信息，综合领域概念库的内容，设计了VRM模型自动构造算法来生成形式化需求模型.总体框架如图2所示，包括：面向领域的自然语言需求模板化处理和模板化的需求到VRM形式化模型的自动构造两大部分.以下分别说明.

图2 面向领域自然语言的VRM模型生成方法研究框架

首先，面向领域自然语言需求，设计定义一套领域自然语言需求模板，对自然语言需求进行规约，得到规范化需求模型.领域自然语言需求模板是根据领域相关知识和实际应用需求进行定义.它是将需求文档中所包含的各种数据、专有名词以及固定句式利用模板和形式化语义进行定义，使得工程人员采用统一且规范的方法描述需求，从而达到减少需求定义过程中所造成的人为失误.领域自然语言需求模板内容包括：领域概念库和领域模板库.

1)领域概念库中主要包括：专有名词，常量，输入变量、输出变量，中间变量，模式集.其中，专有名词指的是领域特有的系统名、组件名等；常量描述的是需求中预先定义的一些常数.输入变量指的是系统状态转换过程中，动态输入的数据；输出变量指的是系统状态转换过程中，值发生改变的一类数据；中间变量指的是有些输入数据需要经过一系列的运算才能最终产生输出数据，为了更好的描述这一过程，添加了中间变量对其进行补充描述.模式集是N个非空不相交的模式的并集，每个模式都是系统状态的等价类.

2)领域模板库结合了领域自然语言需求的句式特征和VRM模型元素的语义特征，设计定义了4种类型模板，分别为：通用条件型模板、通用事件型模板、显示条件型模板和显示事件型模板.

3)利用定义好的领域概念库和领域模板库，对特定领域自然语言需求进行规约，得到可转换为形式化模型的规范化需求.这里的规约，本质上来讲是对一般形式的自然语言描述的需求，按照预定义的需求模板的语义和语法形式，由需求建模人员来进行语义等价的需求条目的模板化、规范化的重构过程.其最终目的是规约后的需求条目，可进行后续内容：使用算法来自动构造VRM需求模型(详细的需求规约过程见5.2节实例分析).这个规约过程以及过程中所用到的模板是建立在领域知识和VRM模型方法论的基础上，目前主要适用于航电软件这类安全关键系统需求建模与分析.

其次，基于规范化需求模型及VRM模型的基本特征，定义了规范化需求模型和VRM模型的数据结构.利用VRM模型的自动构造算法，将规范化需求模型自动构造为VRM模型.

1)利用正则表达式定义领域模板库，从而将需求规约过程中所得到的规范化需求模型进行解析，由此得到需求模型元素，例如：输入变量领域概念、输出变量领域概念等.

2)将解析得到的需求模型元素，利用预定义的需求模型元素-VRM模型元素映射表以及领域自然语言需求模板-VRM表格函数映射表进行映射，由此得到VRM模型元素及构建VRM模型表格函数的相关信息.

3)将得到的VRM模型元素及构建VRM模型表格函数的相关信息进行模型自动化构建，形成VRM模型.

3.2 VRM建模

当前各种形式化方法和理论很多，但是来源于实际工程，并能真正应用于实际工程领域中的需求描述方法很少.并且大多数形式化方法大都采用各种很陌生的符号和逻辑公式来表达模型，这使得绝大多数的形式化方法很难被现有的系统工程人员所理解接受.事实上，工程人员最了解的是工程领域知识，而且在航电系统工程领域中最常见使用的就是各种表格形式(如：各种航电系统操作手册、飞行手册等等)，工程人员最熟悉的也是表格.因此，本文工作中采用的VRM模型就是同时具备表格化和形式化语义的需求模型.

类似于在关系数据库中的数据存储处理方式，VRM模型的直观形式是采用二维表格来建立需求模型.关系数据库中的二维关系数据事实上是由关系演算逻辑系统来严格定义好的数学模型(即：形式化模型).VRM是基于四变量模型，并根据航电软件领域特征进行了剪裁所得到的，其中部分内容的形式化定义如下：

VRM需求规约的六元组：{SV，C，E，F，TS，VR}.其中SV是所有状态变量的集合，为一个四元组，定义为：SV={MV，CV，M，IV}，包含输入变量MV、输出变量CV、模式集M，中间变量IV.下面具体介绍六元组每个数据的功能.

MV：非空的不相交的输入变量的集合，MV={mv1，mv2，…，mvl}，mv1，mv2，…，mvl称为输入变量；

CV：非空的不相交的输出变量的集合，CV={cv1，cv2，…，cvl}，cv1，cv2，…，cvl称为输出变量；

M：非空的不相交的模式集的集合，M={mc1，mc2，…，mcm}，mc1，mc2，…，mcm称为模式，其中mci为某个模式集，它包含了该模式集下的所有模式，Mci={mci1，mci2，…，mcim}；

IV：非空的不相交的中间变量的集合，IV={iv1，iv2，…，ivk}，iv1，iv2，…，ivk称为中间变量；

TS：类型的并集，其中所有的类型都是值的非空集合.

VR：特殊的函数，用来将状态变量的名称映射到具体的值，表示状态变量的所有取值范围.对于VR中的所有r∈VR(r)，r是SV中的某个变量，TS 是r的值域类型.VR(r)是r可能取值的集合.

C：条件，表示单个状态变量上的谓词，如Altitude>500表示当前的高度大于500.条件是逻辑表达式，具有多种表达形式，可以为布尔变量true、false或布尔表达式ci⊙cj等.⊙∈{AND，OR，NOT}表示逻辑操作符；ci=r∘ v.其中∘ ∈{=，<，>，≠，≥，≤}表示关系操作符.

E：事件，表示两个状态变量上的谓词，事件的通用表达式为：

EVENT(S)GUARDD.

EVENT∈{@T，@F，@C}表示事件操作符；GUARD∈{WHEN，WHERE，WHILE}表示守卫操作符；

F：表格函数，所有的表格都是一个数学函数，都可以使用Fi表示.

在VRM模型中，表格函数包括3大类：条件表，事件表和模式转换表.这3类表都有相应的形式化语义定义.限于篇幅，以下仅以示例1和示例2给出简要概述.示例1是一个条件表的例子，语义为：基于状态依赖关系Dn={Pressure，Overriden}定义了输出变量SafetyInjection的取值情况(即某个功能需求F1).其对应的二维表用于直观表示数据逻辑公式语义的形式化模型(见表1).

表1 条件表示例

示例1.

SafetyInjection=F1(Pressure，Overridden)=

{Off if Pressure=high∨Pressure=Permitted∨(

Pressure=TooLow∧Overridden=true)

On if Pressure=TooLow∧Overridden=false

}

示例2则给出一个事件表的例子，是基于新旧状态依赖关系集合：{Block，Reset，Pressure，Overriden}和{Block，Reset，Pressure}，函数定义了输出变量Overridden的值(即某个功能需求F2).其对应的二维表用于直观表示数据逻辑公式语义的形式化模型(见表2).

表2 事件表示例

示例2.

Overridden=F2(Pressure，Block，Reset，Block′

Overridden，Pressure′，Reset′)=

{true if(Block′=On∧Block=Off∧Pressure

=TooLow∧Reset=Off)∨(Block′=On

∧Block=Off∧Pressure=Permitted

∧Reset=Off)

false if(Reset′=On∧Reset=Off∧Pressure

=TooLow)∨(Reset′=On∧Reset=Off

∧Pressure=Permitted)∨(Pressure′=

High∧Pressure≠High)∨((Presurre′=

Permitted∨Pressure′=TooLow)∧(

Pressure=Permmited∨Pressure=

TooLow))

Overridden otherwise(no change)

}

4 建模框架中的核心问题

在本小节中对第3章节研究框架中所涉及到的关键概念，进行详细的设计定义.首先，介绍了使用N元组的形式定义领域概念库中的具体内容；其次，表述了领域模板库的具体内容，以及其组成元素的数学定义；最后描述了VRM模型自动构造的算法及其说明.

4.1 领域概念库

领域概念库是建立在具体的领域及实际的需求中，将需求中所涉及的对象名词，领域概念以及各种数据集中起来，采用规范且符合形式化语义的形式对它们的属性进行描述.领域概念库包含如下内容：专有名词、常量、变量和模式集，其中变量又分为输入变量、输出变量和中间变量，模式继承模式集.

专有名词和对象名称之间是一一对应的关系，例如：EICAS系统中显示功能(对象名称)与专有名词“显示”一一对应.模式集是VRM模型中的一个核心概念，是用来刻画复杂的安全关键系统在运行时候可能处于多种不同的运行模式下(例如：空调有制冷模式集和制热模式集，制冷模式集又包括强风和弱风等模式).模式集的构造事实上是依据VRM模型模式集的建模思想，由需求建模人员对特定领域中系统的运行方式展开基于模式集的分析而建立起来的，VRM模型中模式集的建模概念是提供了一种指导性的模式集构造的框架.不同的需求对象的领域概念库的建立都是来自于工程经验的积累，并没有规则.

本文采取面向对象中类定义的思想对领域概念库中的内容进行定义，如图3所示，并采用N元组的形式进行表示(见表3).

表3 领域概念库语义定义

图3 领域概念库层级关系

领域概念库中所包含的常量及变量定义式中的数据类型(Datatype)，包括系统预定义及用户自定义两部分内容.系统预定义部分包括Boolean，Char，Float，Double，Integer，String和Unsigned.用户自定义数据类型是在系统预定义数据类型的基础上，对值域和精度进行重定义，得到新的更符合实际工程使用的数据类型.新的数据类型定义内容包括：数据类型的名称，类型，值域和精度.可重定义的数据类型包括：Char，Integer，Float，Double，Unsigned和Enumerated.

例如EICAS系统中原始需求，“当ipFADECEngineManualThrottleCmd等于TRUE时，发动机显示器推力参考的图形符号的颜色应为Green 100.”.其中包含：一个输入变量：ipFADECEngineManualThrottleCmd，一个输出变量：opFADECEngineThrustReferenceGraphicColor(来自：发动机显示器推力参考的图形符号颜色)以及一个自定义数据类型color(来自：Green100).该条需求的领域概念库的详细定义如表4所示.

表4 需求示例领域概念库

4.2 领域模板库

领域模板库是采用固定的句式对需求进行规范化描述.本文综合考虑了航空工业领域的需求描述标准，对EICAS系统的需求特征进行分析，将其分为4个基本类型：通用型需求，显示型需求，功能型需求和其它需求.

4.2.1 领域模板

根据对已有的EICAS需求实例进行统计，发现实际需求中多为通用型需求和显示型需求.根据VRM模型的特征，例如：条件表和事件表等.因此，设计了4个基本的领域模板.

1)通用条件：当满足以下条件，<飞机/系统/设备>应能够<功能><对象>：<条件>.

2)通用事件：当发生以下事件，<飞机/系统/设备>应能够<功能><对象>：<事件>.

3)显示条件：当满足以下条件，<对象>应能够<功能><格式/要求/标准>：<条件>.

4)显示事件：当发生以下事件，<对象>应能够<功能><格式/要求/标准>：<事件>.

需求模板中所使用的<飞机/系统/设备>、<对象>、<格式/要求/标准>和<功能>皆为领域概念库中的领域概念，例如：<飞机/系统/设备>就是输出变量和中间变量领域概念.他们已在4.1节进行过严格的定义.<条件>及<事件>的形式化语义将在4.2.2和4.2.3进行定义.

下面以显示条件模板进行举例说明.例如4.1节中的示例，“opFADECEngineThrustReferenceGraphicColor”对应于<对象>，“Green 100”对应于<格式/要求/标准>，“显示”对应于<功能>，“ipFADECEngineManualThrottleCmd等于true时”对应于<条件>.

本文定义的领域模板是在对已有的EICAS实际需求，综合航空工业领域标准、需求特征及VRM模型特征所定义的.后续工作中根据更多的领域特征，综合提炼出更加全面的模板，进而丰富领域模板的内容.

4.2.2 条件模板

条件指的是数据项的取值.条件可能是复合的，即它们是由简单条件组成，并通过逻辑运算符AND，OR，NOT进行连接.

简单条件模板使用三元组定义如下：

ci=(O，R，V)

1)O(Object)：对象，通常为领域概念库中的输入变量.

2)R(Relation)：关系操作，如：=，<，>，>=，<=等.

3)V(Value)：值，是指输入变量取值范围内的一个具体取值.

因此，条件模板采用如下的BNF范式进行定义.c表示简单条件，C_term表示组成条件的项，C表示条件.

c：：=object ′>′ value | object ′<′ value | object ′=′ value | object ′<=′ value | object ′>=′ value

C_term：：=[NOT]c | C_term AND C_term | C_term OR C_term

C：：=C_term | C AND C_term | C OR C_term

例如4.1节中给出的EICAS需求示例的条件可表示为：ipFADECEngineManualThrottleCmd = true.

4.2.3 事件模板

在实际需求中，存在这样的一类需求，它无法使用简单的条件对其进行表达，需要引入一种新的描述机制：事件.例如：当高度低于500时，只要求报警器报警3秒钟，随后不再报警.如果使用条件形式表述，则会出现错误，且报警器会一直处于报警状态，与实际需求所描述的语义不同.所以，此处应该使用事件的形式进行表达.

根据3.2节中<事件>表达式的定义，单个事件有3种：@T，@F和@C.事件操作符和守卫操作符两两组合，有9种，共计12种.

1)@T：表示上一状态_S的值为FALSE，当前状态S为TRUE的事件.即：NOT _S AND S.

2)@F：表示上一状态_S的值为TRUE，当前状态S为FALSE的事件.即：_S AND NOT S.

3)@C：表示当S上一状态的值不等于当前状态的时的事件.即：S ！= _S.

4)WHEN：表示上一状态D为真.

5)WHILE：表示当前状态D为真.

6)WHERE：表示上一状态和当前状态皆为真.

例如：@T(S)WHEN(D)，表示S上一状态为假，当前状态为真，且D上一状态为真.

因此，得到事件模板如表5所示.

表5 事件模板

4.3 模型构造

从规范化需求模型到VRM模型自动构造的过程主要包括两部分：

1)领域概念库的转换：领域概念库转换到VRM模型中的常量字典、变量字典和用户自定义类型.例如：4.1中示例发动机显示器推力参考的图形符号颜色，在领域概念库中为输出变量，需转换到VRM模型中变量字典的输出变量.领域概念库与VRM模型中的数据字典为一一对应的关系.

2)规范化需求的转换：领域自然语言需求经过需求模板的规约操作后，所得到的规范化需求语义为，“在某个条件或者事件下，某个变量(变量为输出变量或者中间变量)取得其值域范围内的一个具体值”.而输出变量、中间变量的值域应至少包含一个数据，所以规范化需求与VRM模型的表格函数为多对一的转换关系.

4.3.1 规范化需求模型

基于上述两个章节定义的内容，给出规范化需求模型数据结构如图4所示.

规范化需求模型主要分为两个部分：领域概念库和规范化需求.领域概念库包含常量概念库、自定义数据类型概念库、输入变量概念库、中间变量概念库、输出变量概念库、模式集概念库、模式概念库和模式转换概念库.规范化需求包括通用条件型规范化需求、通用事件型规范化需求、显示条件规范化需求和显示事件规范化需求.

4.3.2 VRM模型

VRM模型包括常量字典、自定义数据类型、变量字典和行为表.为更好的表达模型信息以及后续工具的具体实现，对其内容进行了整合，转换为常量字典、自定义数据类型、输入变量字典、输出变量(中间变量)条件表、输出变量(中间变量)事件表及模式转换表.综上，给出VRM模型数据结构如图5所示.

图5 VRM模型数据结构

4.3.3 VRM模型构造

VRM模型构造分为3种类型：

1)常量字典、自定义数据类型和输入变量字典的构造.以常量字典为例，构造算法见算法1.

算法1.生成常量字典

输入：ConceptConst

输出：DictionaryConst

1.foreach ConceptConst cc in arrayConceptConstdo

2. DictionaryConstDataValue = cc.getValue()；

3. dc.setDictionaryConst()；

4. arrayDC.add(dc)；

5.endfor；

常量字典构造算法的输入为常量领域概念，输出为常量字典.单个的常量使用4.3.2章节中定义的常量字典类的实例化对象进行存储，常量字典则为常量对象所组成的常量对象数组.通过对常量领域概念对象数组进行遍历，将其中所包含的常量字典语义信息进行转换.因为只进行了一次循环，故算法复杂度为O(n).

2)行为表：输出变量(中间变量)条件表和输出变量(中间变量)事件表的构造.构造算法见算法2.

算法2.生成行为表

输入：ConceptTermVariable.ConceptOutputVariable.StandardRequirement.

输出：BehaviorTable

1.foreach ConceptVariable cv in arrayConceptVariabledo

2. DictionaryVariableDataValue = cv.getValue()；

3.foreach StandardRequirement sr in arraySRdo

4.ifsr.getVariableName().equals(cv.getName())then

5.ifsr.getReqType.euqals("Condition")do

6. ConditionDataValue = sr.getValue()；

7. c.setCondition()；

8. arrayC.add(c)；

9.endif

10.ifsr.getReqType.equals("Event")do

11. EventDataValue = sr.getValue()；

12. e.setEvent()；

13. arrayE.add(e)；

14.endif

15.endif

16.endfor

17. bt.setBehaviorTable()；

18. arrayBT.add(bt)；

18. arrayC = new ArrayList ()；

19. arrayE = new ArrayList ()；

20.endfor

行为表构造算法输入为中间变量领域概念，输出变量领域概念和规范化需求，输出为VRM行为表，包括：中间变量条件表、中间变量事件表、输出变量条件表和输出变量事件表.中间变量领域概念和输出变量领域概念合并存储为变量领域概念.行为表中主要包含两方面内容：变量领域概念内容和规范化需求中包含的行为信息(条件和事件).因此，定义了条件对象数组、事件对象数组以及行为表对象数组.

算法的主要处理过程是先对变量领域概念进行遍历，获取行为表中变量的相关信息.因为一个变量中可能包含条件表或者事件表信息，所以，第2个循环中对规范化需求进行遍历，查找与该变量相关的规范化需求，判断此需求是条件型需求或是事件型需求，将其信息存储到条件或事件对象数组中.最后，将获取到的信息赋值到行为表对象中构成行为表对象数组.因为进行了两层循环，所以算法复杂度为O(n2).

3)模式转换表的构造.构造算法见算法3.

算法3.生成模式转换表

输入：ConceptModeClass、ConceptMode、ConceptModeTran-sition.

输出：ModeMachine

1.foreach ConceptModeClass mc in arrayMCdo

2. ModeClassDataValue = mc.getValue()；

3.foreach ConceptMode cm in arrayCMdo

4.ifcm.getModeClassName.equals(mc.getName())then

5. ModeDataValue = cm.getValue()；

6. m.setMode()；

7. arrayM.add(m)；

9.endif

10.endfor

11.foreach ConceptModeTransition cmt in arrayCMTdo

12.ifcmt.getModeClassName.equals(mc.getName())then

13. BehaviorModeTransitionDataValue=cmt.getValue()；

14. bmt.setBehaviorModeTransition()；

15. arrayBMT.add(bmt)；

16.endif

17.endfor

18. mm.setModeMachine()；

19. arrayMM.add(mm)；

20.arrayM = new arrayList ()；

21.arrayBMT = new arrayList

22.endfor

模式转换表构造算法输入为模式集领域概念，模式领域概念和模式转换领域概念，输出为模式转换表.模式转换表中包含了模式集信息、模式集所包含的模式和模式在相关事件下的转换信息.因此，定义了模式对象数组用于保存模式集下的模式，模式转换对象数组用于保存模式集下的模式之间的转换信息.

算法的主要处理过程是先对模式集领域概念进行遍历，获取模式转换表中模式集的相关信息.因为一个模式集中包含多个模式，所以对模式领域概念进行遍历，获取其中属于当前模式集的相关模式，构成模式对象数组.同时，当前模式集下的模式之间的转换可能存在多个，所以对模式转换领域概念进行遍历，获取属于当前模式集的模式转换数据构成模式转换对象数组.最终形成模式转换表对象数组.因为进行了两层循环，所以算法复杂度为O(n2).

5 EICAS实例分析

5.1 EICAS系统概述

发动机指示和机组警告系统(EICAS，Engine-Indicating and Crew Alerting System)，用来指示飞机各系统工作状态，提供文字、图形和音频信息，出现故障时提示故障和发出警告.EICAS分两个区域：发动机指示和机组警告信息.发动机指示区域包含发动机参数及襟翼位置、燃油量、起落架位置信息等；机组警告信息显示EICAS的右上角，用来提示警示信息和警告信息等.

5.2 EICAS VRM模型生成

考虑到文本篇幅，此处选取实际需求中的一部分需求进行模型的构建及模型的转换工作实例分析.

自然语言原始需求条目.

1)当(参数ipFlightDeckUnitsConfigurationIsMetric有效并且等于TRUE)时，飞机综合电子显示系统应将参数ipFlightDeckUnitsConfigurationIsMetric设置为METRIC，否则设置为IMPERIAL.

2)当ipFADECEngineManualThrottleCmd等于TRUE时，发动机显示器推力参考的图形符号的颜色应为Green 100.

3)如果值ipFADECEngineThrust[L | R]远离值ipFADECEngineThrustCommand[L | R]，则发动机显示器应显示颜色黄色50的命令扇区.

对以上3条原始需求进行领域概念库的构建，得到表6-表9的内容.

表6 输入变量领域概念

表7 输出变量领域概念

表8 中间变量领域概念

表9 自定义数据类型

根据4.2章节定义的领域模板库以及上述定义的领域概念库，对原始需求进行需求规约，得到如下规范化需求条目：

1)当满足以下条件，opFDUConfigurationFormat应能够设置为METRIC：ipFDUConfigurationIsMetric = TRUE AND ipFDUConfigurationIsMetricStatus = Valid.

2)当满足以下条件，opFDUConfigurationFormat应能够设置为IMPERIAL：ipFDUConfigurationIsMetric = FALSE AND ipFDUConfigurationIsMetricStatus = Valid.

3)当满足以下条件，opFDUConfigurationFormat应能够设置为IMPERIAL：ipFDUConfigurationIsMetric = FALSE AND ipFDUConfigurationIsMetricStatus = Invalid.

4)当满足以下条件，opFDUConfigurationFormat应能够设置为IMPERIAL：ipFDUConfigurationIsMetric = TRUE AND ipFDUConfigurationIsMetricStatus = Invalid.

5)当满足以下条件，opFADECEngineThrustReferenceGraphicColor应能够显示为Green 100：ipFADECEngineManualThrottleCmd = TRUE.

6)当满足以下事件，opN1CommandSectorColor应能够显示为黄色 50：@C(tAbsoluteValueCommandAndThrust)when(tAbsoluteValueCommandAndThrust = increasing).

利用VRM模型自动构造算法，对上述得到的规范化需求及领域概念库内容进行转换，得到VRM模型.

上述过程在工具中最终得到的模型如图6所示.

图6 VRM模型

6 相关工作与小结

目前在航电应用领域，从系统及软件需求建模的角度来看，相关工作大致分为如下几类：1)从实际的安全关键系统的工程开发经验中形成的理论与技术，如：四变量模型[13]、SCR方法[14]、RSML方法[15]、CoRE方法[16]、SpecTRM[17]等；2)从通用的软件工程领域产生的软件需求规约方法，如：统一建模语言(UML)[18]中的用例(UseCase)模型[19]的需求捕获与描述方法、从UML扩展而来的系统建模语言(SysML)中用于描述系统需求的参数模型，其典型工具包括了：Raphsody，Statmate[20]等；3)从电子硬件系统设计的同步数据流语言发展而来的需求建模与代码生成技术，如：MATLAB公司的Simulink工具[21]、基于Esterel技术的SCADE工具等；最后一类是以自然语言或者采用限定结构的自然语言来描述系统和软件需求[22].

相比较而言，统一建模语言UML/SysML所提供的图形化符号在完整性、一致性和数学的严谨性上强调的不够.仅使用UML/SysML提供的需求描述方法不足以满足现代安全关键航电系统和软件的需求设计、分析和验证的要求.而基于同步数据流的图形化建模语言(如：Simulink和SCADE)设计初衷为系统和软件的设计，近些年被应用于建模需求规范.但从DO-178C中要求的多层级需求来看，Simulink和SCADE描述的需求模型最多属于DO-178C中的低级需求.其原因是：在这些模型中通常都包含了很明显的设计信息和细节.最后一类限定自然语言的需求方法(如：RSL[23]采用限定的结构化的自然语言描述需求)，通常使用DOORS对条目化需求进行管理.但DOORS本身只是一个需求管理工具，并不能对需求的语义进行检查.因此，当系统的规模增大，所构造的大量需求条目必不可少存在二义性、完整性等问题，显然DOORS工具无法支撑DO-178C任何一个层级的需求分析和验证的任务要求.

本文提出了一种面向领域自然语言需求的模板化规约方法，通过严格定义数学语义的领域概念库和领域模板库，对条目化的自然语言需求进行规约，以减少其二义性.其次，给出了从规范化需求模型到VRM模型的自动转换，包括领域概念库到数据字典的转换规则以及领域模板库到行为表的转换规则.最后，在.net平台上实现了原型工具，并基于实际工业案例EICAS系统进行了案例分析.

在未来的工作中，在领域概念库方面，对已有的一些实例进行领域概念库的构建，以方便工程人员的使用.在领域模板库方面，为了更加贴合实际的工程需求，进一步改进和扩充领域模板，使其更加贴合实际使用的目标工程.VRM模型构建完成后，进行模型的自动化分析，(如：一致性、完整性的检查)，模型元素信息的追踪设计以及测试用例的自动生成等工作.