基于本体的体系使命建模及分析方法

何红悦，王智学，梁豪默，王庆龙

(中国人民解放军陆军工程大学指挥控制工程学院，江苏南京210007)

0 引 言

体系也称为系统之系统(system of systems,SoS),是若干个能够独立运行的系统为了实现一个共同的业务目标而组合在一起的大规模集成系统,具有复杂性、演化性、涌现性、规模性、可变性和网络交互性等特征[1-2]。为了保证体系开发的合理性和有效性,在体系开发的早期,对其开展需求建模显得尤为必要。

当前对体系进行需求建模主要采用体系结构方法,即选择一种体系结构框架，如国防部建筑框架(department of defense architectural framework,DoDAF),UPDM、统一体系结构框架(unified architecture framework,UAF)等做指导,然后使用一种建摸语言(如:(unified modeling language,UML)[3]、(systems modeling language,SysML)[4]等)来描述相关的体系需求模型[5-6]。美军的国防部建筑框架(ministry of defense architectural framework,DoDAF)[7]和英军的(ministry of defense architectural framework,MODAF)[8]主要用于军事领域的体系需求模型构建。对象管理组织(object management group,OMG)则定义了2个体系结构框架的统一概要——unified profile for DoDAF and MODAF(UPDM)用于指导企业体系的构建,OMG又计划将UPDM升级为UAF,UAF采用元模型来定义描述企业体系结构所需要的模型元素与关系,体系建模人员可以采用UAF指导其体系模型的构建[9]。先进系统的综合建模(comprehensive modeling for advanced systems of systems,COMPASS)项目开发了一种体系框架和相应的建模过程指导,使用SysML和COMPASS建模语言(COMPASS modeling language,CML)来构建体系的相关模型[10]。但上述方法都没有强调使命在体系需求建模中的重要作用,尽管他们中有些包含使命元素。使命是体系中各组成系统交互在一起的目的,是体系构建的根本出发点。文献[6-7]构建了体系中使命的概念模型,然后基于该模型开发了mKAOS(missionKAOS)建模语言和工具[11,13],但该方法在使命分解中使用的是KAOS中的使命分解方法,没有把使命的相关属性考虑进去,对分解的合理性和有效性难以分析。课题组前期研究了基于目标或能力的指挥、控制、通信、计算、情报、监视、侦察(即C4ISR)系统需求的相关模型构建技术,但也存在着目标任务分解过程中没有考虑相关属性的问题,对分解结果难以进行分析。

针对上述问题,本文主要围绕基于本体的体系使命建模与分析展开研究。定义了体系中使命建模的概念模型,并设计了相应的使命分解方法,在使命分解时引入了属性参考,便于对结果进行分析。然后采用本体技术,将构建的使命模型性转化为网站网站本体语言描述逻辑(web ontology language description logic,OWL DL)本体,利用本体查询技术来对使命模型展开分析。

1 使命概念模型

DoDAF中将使命定义为:“能够明确表示要采取的行动及任务的原因和目的;分配给某个个体或组织的职责”,没有进一步描述使命概念的相关属性[7]。文献[7]则定义了使命的5个关键属性:优先级、触发、约束、参数和任务,并通过使命模型、职责模型、对象模型、能力模型和涌现行为模型来描述体系的具体使命[12-13]。

使命是体系中子系统的任务在体系这一层次的综合体现。体系中的某个使命是由部分子系统共同完成的,但不是这些子系统完成任务的简单叠加,这些子系统互相协作,实施各自的活动,最终展现出来某个涌现行为,通过该涌现行为来实现相应的使命。每个使命都有与之对应的应用场景和预期效果,不同使命之间存在分解、支持、冲突等关系。使命经层层分解,最终分解为子系统的具体任务,这些任务由子系统执行某种活动来实现。通过分析使命在体系需求建模中与其他概念的关系,构建了使命的概念模型,如图1所示。

图1 使命概念模型Fig.1 Mission conceptual model

根据概念模型,将体系的使命定义为以下多元组:

定义1体系中的使命定义为多元组Mission=,其中

•name表示该使命的名称;

•priority表示该使命的优先级,建模人员在进行体系需求建模时,可以根据需要定义使命优先级的划分范围。

•starttime表示该使命的计划开始时间,endtime表示该使命的计划结束时间;

•Resource表示该使命涉及的全部资源的集合;

•Event表示该使命的触发事件集合;

•Condition表示该使命的守护条件集合;

•Effect表示该使命的预期效果集合;

使命之间的分解、支持、冲突关系分别定义如下:

定义2使命m分解为多个使命m1，m2，…，mn，表示为:Decompose(m,{m1，m2，…，mn}),其中,m是mi的父使命,表示为Farther(m,mi),mi是m的子使命,表示为Son(mi,m),1

使命之间的支持关系可分为强支持和弱支持,强支持表示一个使命的实现必须依托于另一个使命的实现,弱支持表示一个使命的实现不必依托于另一个使命的实现,但另一个使命的实现可以增强该使命实现的最终效果。

定义3使命m1强支持使命m2表示为:SSupport(m1,m2)。

定义4使命m1弱支持使命m2表示为:WSupport(m1,m2)。

使命之间的冲突关系也可分为强冲突和弱冲突,强冲突表示两个使命不可同时实现,只能有一个实现,弱冲突表示两个使命可以同时出现,但会减弱彼此的实现效果。

定义5使命m1强冲突使命m2表示为:SConflict(m1,m2)。

定义6使命m1弱冲突使命m2表示为:WConflict(m1,m2)。

2 使命分解方法

体系使命模型的构建过程就是对体系中最高使命的分解细化过程。每个体系都有一个最高层的使命,通过对该使命进行逐层分解,细化到体系中子系统能够执行的任务,表明使命模型构建完毕。最终的使命模型是一个以最高使命为根节点的使命分解树,树的各个非叶节点表示体系的各个使命,叶节点表示子系统执行的任务。下面从分解模式、分解原则和分解树构建算法3个方面介绍使命分解方法。

2.1 分解模式

在面向目标的需求分析中,对目标的分解主要采用与/或分解模式。本文以该分解模式为基础,定义了体系中使命的3种分解模式。

定义7或分解模式,如果Decompose(m,{m1，m2，…，mn}),只要子使命mi实现,父使命m就可以实现,则称m1，m2，…，mn为m的或分解。

定义8并行分解模式,如果Decompose(m,{m1，m2，…，mn}),所有子使命mi实现后,父使命m才实现,并且子使命的实现是各自独立完成的,没有任何先后关系,则称m1，m2，…，mn为m的并行分解。

定义9串行分解模式,如果Decompose(m,{m1，m2，…，mn}),所有子使命mi实现后,父使命m才实现,并且mi-1结束后,mi才开始,则称m1，m2，…，mn为m的串行分解。

2.2 分解原则

在使命的逐层分解过程中,为了保证各层使命之间在属性值上的一致性,即子使命的属性值不能与父使命的属性值发生冲突,要求在使命分解过程中遵守以下原则:

(1) 优先级原则

使命的优先级是可以通过父使命传递给各个子使命的,如果使命m1的优先级高于使命m2的优先级,则使命m1的子使命的优先级不能低于使命m2的子使命的优先级。在使命分解过程中,为了保持优先级的传递性,要求每个子使命的优先级不能高于父使命的优先级。

(2) 时间原则

所有子使命的处理时间窗口应在父使命的处理时间窗口之内。在或分解模式和并行分解模式下,任意子使命mi的计划开始时间不能早于父使命的计划开始时间,计划结束时间不能晚于父使命的计划结束时间。在串行分解模式下,子使命m1的计划开始时间不能早于父使命的计划开始时间,子使命mn的计划结束时间不能晚于父使命的计划结束时间。

(3) 资源原则

所有子使命的资源集合的并集正好是父使命的资源集,即∪Resourcei(1≤i≤n)=Resource。

(4) 事件原则

在或分解模式和并行分解模式下,所有子使命的事件集合的并集正好是父使命的事件集,即∪Eventi(1≤i≤n)=Event。在串行分解模式下,子使命m1的事件集是父使命的事件集,即Event1=Event。

(5) 守护条件原则

所有子使命的守护条件集合的并集正好是父使命的守护条件集,即∪Conditioni(1≤i≤n)=Condition。

2.3 分解树构建算法

体系的使命分解由最高层的使命开始,最终分解得到以该使命为根节点的使命分解树。使命分解树构建算法如下:

输入体系的最高层使命m。

输出使命分解树T。

算法过程:

步骤1创建一个使命队列Qm,将使命m添加到队列Qm中,然后创建仅包含使命m的树T;

步骤2从队列Qm中取出一个使命m′;

步骤2.1如果使命m′可以分解,则使用相应的分解模式,将使命m′分解为m1，m2，…，mn,将分解得到的使命添加到队列Qm中,并将这些使命作为使命m′的子节点添加到使命树T中,最后将使命m′从队列Qm中删去;

步骤2.2如果使命m′采用的是串行分解模式,在使命树T中建立各个子节点的时序指针;

步骤2.3如果使命m′不可分解,则将使命m′映射到体系中子系统执行的某个任务上,最后将使命m′从队列Qm中删去;

步骤2.4如果队列不为空,则继续执行步骤2;

步骤3分析使命树T中各个使命之间的支持、冲突关系,并将这些关系指针添加到使命树T中。

步骤4返回构建完成的使命分解树T。

3 模型形式化

为了使用本体技术对构建的使命模型进行分析,需要将使命模型形式化为OWL DL表示的本体知识库。OWL DL是一种本体描述语言,以描述逻辑SROIN为逻辑基础。OWL DL本体分为类和实例两部分。在形式化使命模型时,需要将使命概念模型中的相关概念形式化为描述逻辑SROIN知识库中的Tbox,即转化为OWL DL本体的类定义;将使命模型中的各个使命形式化为描述逻辑SROIN知识库中的Abox,即转化为OWL DL本体的实例声明。

根据使命模型分析的需要,从使命概念模型中提取的描述逻辑SROIN知识库的类和关系分别如表1、表2所示。

表1 使命模型类列表

表2 使命模型关系列表

根据提取的类和关系及构建的使命模型来构建描述逻辑SROIN知识库,即分别构建知识库的Tbox和Abox。下面介绍两者的构建算法,首先是构建Tbox的算法:

输入表1和表2。

输出Tbox。

算法过程:

步骤1创建一个空Tbox;

步骤2对表1中的概念C,在Tbox中创建与C同名的类;

步骤3对表2中的关系R=(C1,C2),在知识库Tbox中添加类公理C1⊆∀R.C2和C2⊆∀R～.C1,R～为R的逆关系;

步骤4对关系R在值域C2端的基数约束“0.1”、“1.*”、“1”,在知识库Tbox中分别添加类公理C1⊆≤1R.C2(表示约束“0.1”,即和C1有R关系的C2个体最多有一个)、C1⊆≥1R.C2(表示约束“1.*”,即和C1有R关系的C2个体至少有一个)、C1⊆≤1R.C2(表示约束“1”,即和C1有R关系的C2个体仅有一个)和C1⊆≥1R.C2(表示约束“1”,即和C1有R关系的C2个体仅有一个);

步骤5对关系R在定义域C1端的基数约束“0.1”、“1.*”、“1”,在知识库Tbox中分别添加类公理C2⊆≤1R～.C1(表示约束“0.1”,即和C2有R关系的C1个体最多有一个)、C2⊆≥1R～.C1(表示约束“1.*”, 即和C2有R关系的C1个体至少有一个)、C2⊆≤1R～.C1(表示约束“1”,即和C2有R关系的C1个体最仅有一个)和C2⊆≥1R～.C1(表示约束“1”,即和C2有R关系的C1个体最仅有一个),R～为R的逆关系;

步骤6返回Tbox。

创建Abox的算法如下:

输入使命模型

输出Abox

算法过程:

步骤1创建一个空Abox;

步骤2遍历使命模型中使命分解树的每个使命节点m=,在Abox中添加个体声明Mission(name)、Resource(resourcei)、Event(eventi)、Condition(conditioni)和Effect(effecti),添加关系声明Priority(name,priority)、Starttime(name,starttime)、Endtime(name,endtime)、Trigger(eventi,name)、Constraint(conditioni,name)和Concern(name,resourcei),其中i表示对于集合Resource、Event、Condition中的任意一个元素都执行该操作;

步骤3对于使命节点m和它的父节点m′,添加关系声明Decompose(m′,m);如果m和其他使命节点m1之间存在支持、冲突、串行等关系,添加相应的关系声明SSupport(m,m1)、SConflict(m,m1)、WSupport(m,m1)、WConflict(m,m1)、Sequence(m,m1);

步骤4返回Abox。

OWL DL本体的逻辑基础是描述逻辑SROIN[14],将构建得到的知识库Tbox和Abox使用OWL Dl语言描述出来,从而得到了使命模型的OWL DL本体。

4 模型分析

使命模型的优劣会影响到体系后续的开发建设工作,因此需要对使命模型进行分析,及早发现模型中的错误。本文使命模型分析中主要关注两个方面:一是使命分解中是否遵守了5个分解原则;二是分解的使命之间在冲突、支持和串行关系上是否存在矛盾。本文使用本体查询方法来检测使命模型中可能存在问题,将这些检查问题转换为用SPARQL(simple protocol and RDF query language)[15]表示的本体查询规则,然后利用本体推理引擎Pellet,针对每条查询规则对使命模型的OWL DL本体进行查询,查找模型中是否存在有问题的使命。具体查询规则如下:

(1) 优先级原则检查,即检查模型中是否存在违背优先级原则的使命节点,SPARQL查询规则如下:

SELECT?m WHERE{?m rdf:type xmlns:Mission.? a xmlns:Decompose?m.?m xmlns:Priority?b.?a xmlns:Priority?c.?b swrl:bigger?c.}.

(2) 时间原则检查,即检查模型中是否存在违背时间原则的使命节点,SPARQL查询规则如下:

SELECT ?m WHERE {?m rdf:type xmlns:Mission. ?a xmlns:Decompose ?m. ?m xmlns:Starttime ?b. ?a xmlns: Starttime ?c. ?c swrl:bigger?b.};

SELECT ?m WHERE {?m rdf:type xmlns:Mission. ?a xmlns:Decompose ?m. ?m xmlns:Endtime ?b. ?a xmlns:Endtime ?c. ?b swrl:bigger?c.}。

(3) 资源原则检查,即检查模型中是否存在违背资源原则的使命节点,SPARQL查询规则如下:

SELECT ?m WHERE {?m rdf:type xmlns:Mission. ?a xmlns:Decompose ?m. ?m xmlns:Concern ?b. UNSAID {?a xmlns:Concern ?b.}.}。

(4) 事件原则检查,即检查模型中是否存在违背事件原则的使命节点,SPARQL查询规则如下:

SELECT ?m WHERE {?m rdf:type xmlns:Mission. ?a xmlns:Decompose ?m. ?b xmlns:Trigger?m. UNSAID {?b xmlns:Trigger ?a.}.}。

(5) 守护条件原则,即检查模型中是否存在违背守护条件原则的使命节点,SPARQL查询规则如下:

SELECT ?m WHERE {?m rdf:type xmlns:Mission. ?a xmlns:Decompose ?m. ?b xmlns:Constraint ?m. UNSAID {?b xmlns:Constraint ?a.}.}。

(6) 模型中是否存在两个使命,彼此之间既是支持关系,又是冲突关系,SPARQL查询规则如下:

SELECT ?m ?n WHERE {?m rdf:type xmlns:Mission. ?n rdf:type xmlns:Mission. ?m xmlns:SSupport ?n. ?m xmlns:SConflict ?n.};

SELECT ?m ?n WHERE {?m rdf:type xmlns:Mission. ?n rdf:type xmlns:Mission. ?m xmlns:SSupport ?n. ?m xmlns:WConflict ?n.};

SELECT ?m ?n WHERE {?m rdf:type xmlns:Mission. ?n rdf:type xmlns:Mission. ?m xmlns:WSupport ?n. ?m xmlns:SConflict ?n.};

SELECT ?m ?n WHERE {?m rdf:type xmlns:Mission. ?n rdf:type xmlns:Mission. ?m xmlns:WSupport ?n. ?m xmlns:WConflict ?n.}。

(7) 模型中是否存时序冲突的使命组合,如果m1和m2之间存在时序关系,m3和m4之间存在时序关系,m1和m4之间存在强支持关系,m2和m3之间存在强支持关系,则m1和m2之间的时序关系与m3和m4之间的时序关系存在冲突。SPARQL查询规则如下:

SELECT ?m ?n ?a ?b WHERE {?m xmlns:Support ?b. ?n xmlns:SSupport ?a. ?m xmlns:Sequence ?n. ?a xmlns:Sequence ?b.}。

(8) 模型中是否存在2个使命,彼此之间既是强支持关系,又是串行关系,但被支持使命在支持使命开始时就结束了,SPARQL查询规则如下:

SELECT ?m ?n WHERE {?m rdf:type xmlns:Mission. ?n rdf:type xmlns:Mission. ?m xmlns:SSupport ?n. ?n xmlns:Sequence ?m.}。

5 案例分析

军事电子信息系统是军队体系作战的重要支撑,由多个相关业务领域的子系统构成,是军事和国防领域的一个体系[16]。以军事电子信息系统中的区域防空指挥系统为例,采用本文的方法构建其需求建模中的使命模型。如图2所示为建模工具构建的区域防空指挥系统的使命模型(项目组根据本文提出的方法开发了一个建模与分析工具)。

图2 区域防空指挥系统使命模型Fig.2 Mission model of regional air defense command system

在该使命模型中,“获取信息优势”和“目标拦截”虽然是两个独立的使命,但获取战场的信息优势可以增大对入侵空域目标的拦截成功率,因此在他们的子使命中,存在着相互关系。“获取信息优势”中子使命“电子侦查”可以串行分解为3个顺序关系的子使命:目标识别、目标定位和目标跟踪。目标拦截子使命导弹拦截可以串行分解为两个顺序关系的子使命:发现目标和导弹拦截。其中发现目标需要目标识别和目标定位的强支持,导弹摧毁需要目标跟踪的强支持。由于目标识别和目标定位是顺序关系,根据强支持关系的含义,目标识别和发现目标之间的强支持关系是多余的。通过本体查询,使用查询规则7,就可以检查出存在的多余关系。

6 结束语

对体系进行需求建模分析是体系早期获得相关信息并用于辅助体系设计、分析与论证的重要手段,其中使命建模在体系需求建模中处于重要地位。本文研究了基于本体的体系使命建模与分析方法。从分析体系的使命概念模型入手,根据体系中使命概念模型,设计了体系使命模型的构建方法。为了分析构建后的使命模型,将模型形式化为OWL DL本体,并将分析检查的内容转化为本体查询规则,借助本体推理工具实现模型分析功能。针对不同的检查内容可以设计相应的查询规则,使得模型的分析具有灵活性和可扩展性。