基于DoDAF的可执行模型改进方法
2016-11-02刘正张新强王鸿飞乔可春
刘正 张新强 王鸿飞 乔可春
1.解放军理工大学指挥信息系统学院江苏南京210007 2.中国电子设备系统工程公司研究所北京100141 3.61516部队北京100094
基于美国防部体系结构框架(Department of Defense Architecture Framework,DoDAF)[1]建立的体系结构是对系统的静态描述,还不足以支撑系统动态特性的分析.Levis和Wagenhals提出了可执行模型的思想[2−3],即综合体系结构中相应静态视图产品(OV5、OV6a、OV7以及OV6b)中的信息,以可追溯的方式映射到可执行模型(Coloured Petri Nets,CPN)中,通过模型的执行或数学分析,使得在顶层设计阶段充分描述和理解系统的行为和性能成为了可能.后来的许多研究[4−10]都是在这一基础上,进一步探索了这4类产品向其他可执行模型(如OPN[6]、HCPN[9]、Simulink[10]等)转换的方法.但以上所选的体系结构产品构建的可执行模型,对系统行为的分析只是局限于逻辑层面,无法支撑实际的动态行为分析.本文以DoDAF1.0下的OV作为研究对象,通过改进Levis和Wagenhals可执行模型的构建思路,扩展了可执行模型对系统动态行为的验证范围,最终结合具体案例,介绍改进后的可执行模型的构建步骤与过程分析.
1 构建思路
1.1 Levis和Wagenhals的构建思路分析
1)选择参与构建可执行模型的基本视图产品.Levis和Wagenhals认为,在DoDAF下,OV5描述了通常情况下实现使命任务或业务目标所进行的活动,当OV5按照OV6a描述的规则动态地执行、处理或消耗OV7中定义的数据时,就会展现出系统业务层面的动态行为.而OV6b定义了用户期望的系统状态转换过程,它为系统动态行为状态转换提供了一致性评价的标准.
2)建立产品与可执行模型之间的转换规则.CPN[11]是Petri网的高级形式,它除了具有普通Petri网展现建模对象动态特性、表征系统竞争和冲突现象的能力外,还增加了以下优势:一是为Petri网中的Token赋予了颜色,通过建立颜色集,能够方便地描述复杂数据实体;二是通过弧表示、守卫函数以及代码片断,提高了复杂点火规则的可读性;三是CPN具有层次结构,能降低模型复杂度.
上述4类体系结构产品向CPN模型转换的映射规则如图1所示.首先,将OV5(以IDEF0描述的模型为例)作为可执行模型的基本结构,其中ICOM箭头转换为CPN模型中的库所(P),活动转换为模型中的变迁(T),库所与变迁之间的弧线方向与OV5中箭头的方向一致,若OV5具有层次结构,则将其分解模型分配到CPN模型的子层上重复上述转换;其次,将OV7的数据结构转换为模型的全局声明,将OV6a中的规则变为模型的守卫函数、弧表示或代码片断;最后,将CPN的运行初态设置为OV6b的初始状态.这样构建的CPN模型,其所有要素都可回溯到参与构建的体系结构产品,因此在描述系统动态行为方面与体系结构产品保持了一致.
3)可执行模型的动态分析.一种方法是直接运行模型,这种方法既能向用户直观展示系统的动态行为,也能即时发现运行过程中死锁、并发冲突等逻辑问题出现的位置,但仿真运行可能无法遍历模型的所有状态,难免会遗漏潜在的动态逻辑问题;另一种方法是利用工具全面验证可执行模型的状态转换.CPN Tools是由丹麦Aarhus大学计算机科学系和美国宇航局联合推出的CPN建模、仿真与分析工具,它具有可视化仿真界面,并且包含模型状态分析功能,能够描述可执行模型完整的状态发生图,便于进行状态的一致性分析.Levis和Wagenhals正是利用这一工具进行了可执行模型的建模与分析.
上述方法的局限性,主要在于参与构建模型的体系结构产品还不够丰富,影响了模型的验证能力.正如DoDAF中指出,业务层面涉及的系统动态行为是指业务过程的动态行为引起的事件时序[1],它不仅包括OV5在OV6a、OV7以及OV6b支持下展现的逻辑层面的系统行为,同时还包括活动部署到执行节点后的实际动态行为(如系统能否在正确的节点、按照正确的顺序执行正确的活动、交付或使用正确的信息).由于系统实际动态行为的评估既涉及到节点内活动的逻辑关系,又需要考虑到节点之间的关联关系,因此在构建可执行模型时,需要OV2(节点连接描述)的参与.
1.2 可执行模型的改进方案
OV2描述了特定活动(或任务)的执行节点,建立了节点间产生、使用和处理信息的关联关系,这一关联关系本质上是节点间活动的交互,因此OV2隐含了OV5中活动的逻辑连接关系,但是OV2本身并没有显性地描述活动间的逻辑连接,因此本文的基本思路是:以OV2为主体,通过推理或约定,将OV5中活动的逻辑连接关系拓展到OV2,明确节点间/内活动的逻辑连接,形成OV2与OV5融合模型.
OV2与OV5融合处理包括两个关键环节:
1)确立节点间活动的逻辑连接.因为节点间活动的逻辑连接隐含于节点间信息交换关系之中,因此可以通过推理来获得.
推理1(节点间活动的逻辑连接):在OV2中,如果从节点Ni到Nj存在信息交换,那么这条信息交换必定来源于OV5中的某两个活动(假设为Am和An)之间的信息交互,且节点Ni和Nj当前分别部署了活动Am和An,因此可以建立从节点Ni中活动Am到Nj中活动An之间的逻辑连接.(当节点、活动为外部节点、外部活动时,可能并未在体系结构中描述,在推理节时假设其存在).
2)确立节点内活动的逻辑连接.由于OV2并没有描述节点内的信息交换关系,所以节点内活动的逻辑连接,无法利用推理1得出.在此作如下约定:
图1 体系结构产品向视图级CPN转换思路
约定1(节点内活动间的逻辑连接关系):如果节点内的某些活动之间在OV5中存在逻辑连接关系,那么在节点内这些活动之间也应该建立相应的逻辑连接.
约定2(节点内活动的无源控制与机制箭头的逻辑连接):若节点内的活动在OV5中具有无源控制或机制箭头,同时这些箭头未构成节点间的信息交换,则依据其在OV5中的逻辑位置添加至节点相应的活动上.
OV2与OV5融合模型增加了节点与信息交换的描述,因此需要增加节点、信息交换以及节点层次关系向CPN转换的映射规则,如表1、表2所示.
表1 节点、信息交换、节点层次关系向CPN转换映射
表2 节点层次关系向CPN转换映射
2 OV视图案例
下面以一个简化的执行空中拦截使命任务的OV作为案例进行分析,图2为高级作战概念图OV1,基本想定为:
图2 OV1高级作战概念图
1)设置1个空中指挥中心节点,进行决策和下达命令;
2)设置2个侦察节点,其中1个侦察节点根据空中指挥中心的命令执行常规侦察活动,另一侦察节点随时待命,根据空中指挥中心命令择机参与侦察活动;
3)设置1个行动节点,根据空中指挥中心命令派遣拦截机执行拦截任务.
其简化的作战流程如下:
1)常规侦察节点执行常规侦察任务;
2)当有不明飞行物体接近使命空域时,常规侦察节点感知并向空中指挥中心报告;
3)空中指挥中心进行不明飞行物的敌我识别;
4)空中指挥中心根据识别结果,进行决策:
a)若不明物为我机,则转向1);
b)若不明物为敌机,则向行动节点下达拦截命令,转向6);
c)若不明物未识别:
和平环境下,向待命侦察节点下达定向侦察命令,转向5);
战争环境下,向行动节点下达拦截命令,转向6);
5)待命侦察节点进行感知、识别判断后,向空中指挥中心报告,返回4);
6)行动节点接到命令后,出动拦截机,展开行动.
具体的运营规则(OV6a)如表3所示:
表3 规则模型OV6a(结构化英语if..then)
续表3
续表3
图3~图6是根据想定案例生成的OV的其他体系结构产品,分别为:OV2、OV5、OV7以及OV6b.
基于体系结构产品构建可执行模型的必要前提是体系结构产品完成了静态一致性验证,由于本文重点研究的是可执行模型的改进,所以关于产品静态一致性验证过程在此省略.
图3 OV2节点连接描述图(层次化分解)
图4 OV5活动模型(IDEF0)
图5 OV7数据模型
图6 状态转换模型(OV6b)
3 可执行模型的构建
3.1 可执行模型的改进方案
依据1.2节的推理和约定,首先对OV2、OV5进行融合处理,步骤如下:
Step1:选择OV2中的叶节点作为初始点.叶节点中分配的活动可能有两种:一种是可再分解的父活动,另一种是不可再分的叶活动.若叶活动属于父活动的分解活动,则只保留父活动.
Step2:新建子层,在子层中建立叶节点间/内活动的逻辑连接.
Step3:若该层内存在可再分的父活动,则继续新建子层,插入该父活动的分解模型,直至结束.
通过上述步骤可以得到OV2与OV5的融合模型.如图7所示.
3.2 构建CPN模型
首先依据图8建立CPN的基本结构,再结合OV7、OV6a以及OV6b完善CPN模型,步骤如下:
Step 1:从OV2与OV5的融合模型开始,自顶向下按照“节点-子节点-活动-子活动”的顺序将融合模型的层次结构变为CPN的层次结构,每个节点、活动变成CPN对应层次的变迁,信息交换、ICOM箭头变成库所,建立库所与变迁的连接弧;
Step 2:根据OV7建立CPN模型全局声明;
Step 3:根据OV6a建立CPN中的弧表达、守卫函数或代码片断;
Step 4:按照OV6b的初始状态设置CPN的运行初态.
由于篇幅所限,在此只显示整个CPN的3个模型:顶层节点连接模型、N1节点分解模型、以及N1.2节点中Sense活动分解模型.如图8所示.
图7 明确活动逻辑连接关系的OV2与OV5融合模型
图8 CPN可执行模型(节选)
图9 CPN模型状态发生图
3.3 可执行模型分析
在1.1节中已经概述了CPN模型的两种动态分析方法,本文着重介绍后一种方法,图9所示即本文构建的CPN模型的状态发生图,它是带有状态节点与弧的有向图,每个状态节点上包含3个数字,最上面的数字为状态节点的标识,下方两个数字,例如1:2,前者代表该状态节点有1个前状态节点,后者代表其有2个后状态节点.每个状态节点定义了CPN模型的一个状态,状态节点可以展开,展开后能够显示当前状态节点下整个CPN模型所有库所中包含的Token集合,如图中状态节点11下方方框所示,而每条弧线的方向代表了状态转换发生的方向,弧线展开后,可以显示引起状态变化的变迁名字、激活该变迁的条件等,如图中状态节点8->11的弧所示.
通过状态发生图,可以对案例体系结构的动态行为进行以下几方面分析:
1)体系结构的状态转换是否与用户渴望的状态(OV6b)一致.以状态节点8->11的弧为例,它表示N3节点中的活动Act在收到需拦截的威胁标识(tid=1)并存在可用拦截机(iid=1)的条件下能够满足变迁的点火规则,从状态8转到状态11.这与OV6b 中从 “N2deciding act”到 “N3act intercept”的状态变化条件是一致的.
2)部署在不同节点的相同活动的执行时机.图中标注了节点N11中的活动Detect执行可能导致的状态转换:1->1、1->2,节点N12中Detect活动执行可能导致的状态转换:7->9、7->10、18->9、18->20.通过分析可以发现,对于设定的单一威胁来说,节点N11中的Detect活动仅在初始时参与了执行,引起状态转换(1->1未侦察到威胁、1->2侦察到威胁),后续与Detect活动相关的状态转换均由N12节点引起的,这与OV6b中描述的是一致的.
3)通过动态分析发现状态转换过程中存在的循环过程.针对循环过程,可以详细分析体系结构的动态行为是否存在死循环的可能.我们在图中用自然语言描述了状态5->7->10->14->5这一循环过程的状态变化条件,从中可以发现,当待命侦察节点收到定向侦察命令后,若探测概率低将一直无法侦察到威胁,继而无论其识别威胁的概率有多高,在逻辑上待命侦察节点都不会识别威胁,那么在和平环境下,就会导致空中指挥中心不断命令其执行定向侦察活动,从而使整个运营流程进入一个不断循环的状态.
4 结论
本文在OV5、OV6、OV7等产品的基础上将OV2纳入构建可执行模型的体系结构产品序列中,能够更深入地分析系统业务层面的动态行为,通过评估活动部署后实际运行的动态特性,使体系结构的动态特性得到了更充分的验证.
对于当前As-Is体系结构,在上述可执行模型中可以进一步考虑节点的人员/设备资源、活动的执行成本、时间等因素,通过收集可执行模型的运行数据,统计分析体系结构节点资源占用率、运行成本、时间效率等关键指标,查找体系结构中可能存在的短板,可为将来的To-Be体系结构的改进完善打下基础.