米巧丽,徐廷学,刘 勇
(1.海军航空工程学院 研究生管理大队,山东 烟台 264001;2.海军航空工程学院 兵器科学与技术系,山东 烟台 264001;3.海军航空工程学院 接改装训练大队,山东 烟台 264001)
舰炮作为一种反应快、持续作战能力强、效费比高的舰载武器,是水面舰艇在未来联合作战中对岸、对空、对海作战不可缺少的重要武器装备。舰炮维修保障的目的是依据舰炮在各个任务剖面下的保障要求进行专项维修保障,保证装备在有限的维修保障资源情况下完成规定任务,从而提高舰炮对敌目标的打击能力及平时和战时的综合保障能力[1]。根据舰炮的使命任务和保障要求,其保障过程涉及到多活动、多资源、多组织在多任务阶段的有效协调和应用。场景是为了完成特定任务而按照时间顺序排列的一系列对象间的交互,是对象交互的特定时序[2]。场景技术常用于描述系统行为、系统与环境之间的交互,可以根据特定任务的具体事例进行分析,对复杂系统要求的分析与研究十分有利。针对舰炮使命任务及各任务阶段维修保障的复杂性与特殊性,拟将场景技术、行为树与对象Petri网相结合的建模方法应用于舰炮任务阶段维修保障过程的建模与验证中,以有效地模拟并发现舰炮在各任务阶段中的保障缺陷,从而针对性地规划舰炮任务过程中的保障活动和资源,提升保障系统的保障能力。
舰炮的主要使命任务是:对岸上的目标进行摧毁、压制,对岸攻击和火力支援;与其他武器装备配合,对海上的中小目标实施打击,应对低强度海上冲突及警告性打击等;承担舰艇及要地的近程、末端防空及反导防御等[3]。依据任务过程通常将舰炮使命任务分为任务准备、执行任务、任务结束和待命等阶段。由此,对应将舰炮的任务场景划分为如图1所示的任务准备场景、执行任务场景、任务结束场景及待命场景。其中,执行任务场景按照作战任务分类进一步划分为对海作战场景、对岸作战场景和对空作战场景。
基于上述任务场景,在舰炮维修保障的实施过程中,构成舰炮维修保障的基本要素为各种随机或计划的事件,如发生故障、申请备件、修复性维修、执行任务和预防性维修等。这些事件均是发生在离散的时间点上。舰炮维修保障对象的状态也是由一系列的离散变量所表征,如备件库存量、维修人员数量、保障设备可用数量、待修装备与可用装备数量等。当一个离散事件发生时,如产品发生故障,系统的离散变量将随之改变,表征系统的状态发生跃变。而系统将在该事件的驱动下,根据跃变前的状态和外界输入,确定如何进行状态转移。如装备发生故障后,有可能立即进入维修流程,也有可能排队等待维修。这些行为特征体现了离散事件系统的“离散事件驱动系统状态的跃变,系统状态的跃变触发新的离散事件”的动态特性[4]。因此,舰炮维修保障过程表现出典型的离散事件动态特性。
目前常用的离散事件系统过程建模方法主要包括EPC、IDEF3、Petri网、UML 和行为树等有代表性的方法[5]。其中,行为树(Behavior Tree,BT)是一种形式化的、用于表示单个实体或实体网行为的树状图,可对实体实现或改变状态、做出决策、响应/触发事件、交换信息等进行描述[6]。根据舰炮任务场景及维修保障过程特性,从建模需求、范围和能力等方面对这些建模方法进行比较发现:常用的单一建模方法对任务及保障过程中各活动、资源及组织的关系描述精度不够,建模过程冗长,无法满足任务变化的保障需求,并缺乏优化重组的能力。相对而言,行为树方法具有较好的描述能力,不但可以准确地反映单个任务场景中的维修活动,并可以通过单元组合创建满足多个任务场景交互的维修保障过程模型,但是其在模型动态验证和定量分析等方面有所欠缺;Petri网方法在描述能力、易用性及对维修过程相关元素的描述等方面有所欠缺,但其可以有效地进行模型动态验证与定量分析,可为描述具有离散事件动态特性的复杂系统提供强有力的手段。可见,行为树与Petri网方法在各方面相辅相成,从而满足基于任务场景的舰炮维修保障过程的建模要求。因此,首先运用行为树方法对基于任务场景的舰炮保障过程进行描述,然后集成子模型并转换为可执行的Petri网仿真模型进行仿真验证。
依据行为树基本构成和舰炮维修过程的分析,在预防性维修和修复性维修过程中,如果等待维修的故障件较多,而维修站点或维修资源有限,那么将会出现排队现象,因此,需要对每个维修活动相关的资源等待时间及维修时间等加以统计。行为树要完整地反映过程中活动、资源及组织相互之间的关系,并且直观有效地转换为Petri网模型进行模型验证,其缺乏对维修保障过程中资源使用、等待时间与维修时间等性能参数的描述。
行为树的基本组成单元是与逻辑表达式及数量公式等形式化基础上的事件、决策或状态等内容相关的窗体元素[7]。依据上述问题,对基础行为树进行扩展,简记为扩展行为树(extended Behavior Tree,eBT)。eBT 的基本组成单元表示如图2所示,对基础行为树的组成单元进行两方面扩展:
1)加入所描述事件和活动对应的保障资源信息。对各种保障资源进行编号,如备件1记为P1,设备1记为Q1,维修人员1记为W1。
2)在活动状态单元中加入等待时间TW和维修时间TM等性能参数信息。
舰炮在使用阶段会面临多个任务场景,而每个任务场景中可能包含一个或多个维修实例。描述每个维修实例的行为树中可能包含多个系统状态(舰炮状态)、输入事件、内部事件、输出事件、活动、条件判断及这些元素相互之间的关系等元素。将基于任务场景的舰炮维修保障过程形式化描述为Sys={Si|Si∈S},其中Si是属于整个舰炮任务场景集S中的场景,如记待命场景、任务准备场景、执行任务场景及任务结束场景分别为S0、S1、S2、S3。对每个任务 场 景Si={Rij,i=0,1,2,3,j=0,1,2,…,N},Rij=(Staij,Eij,Conij,Actij,Reij)为场景Si的实例集,其中,Staij代表实例Rij的系统状态集;Eij=In_eij∪Inner_eij∪Out_eij代 表 实 例Rij中 的 事 件 状态集合,其中,In_eij、Inner_eij与Out_eij分别是实例Rij中输入事件状态集合、内部事件状态集合与输出事件状态集合;Conij={Conijk,0≤k≤M}为实例Rij中的条件判断集合,条件判断Conijk可表示为(Conijk-e,Conijk-Para)或Conijk-exps,其中,Conijk-e、Conijk-Para与Conijk-exps分别为实例集Rij中的任意条件判断Conijk中使用的事件状态、事件参数集与表达式集;Ackij为实例Rij中的活动集合;Reij为实例Rij中各个元素之间关系的集合,如系统状态与输入事件状态之间的关系可表示为Reij(Staij,In_eij)。
对于舰炮保障系统来说,当舰炮装备处于待命状态时可进行预防性维修,它是一个固定时间触发。如在待命场景S0中,规定舰炮每执行任务累积时间达到t0后需进行一次预防性维修作业。在任务准备阶段首先要为任务分配装备,此时主要考虑装备是否完好,故障或未完成维修的装备不能执行任务。当任务启动时,如果准备完毕的装备达到任务的保障要求,则装备进入任务执行阶段。因此,当舰炮接受任务命令时,如果任务累积时间在t0之内则进入任务准备阶段,如超过t0则进入相应维修站点进行预防性维修。舰炮在进入任务准备阶段后,进行故障检测,如果不出现故障则正常执行任务,如出现故障则进入故障维修流程。上述待命与任务准备场景下维修保障过程的eBT 模型如图3所示。
在任务准备与执行任务场景中,如果舰炮的某一系统或产品故障发生故障或遭受战损,须进行修复性维修。维修可以在不同级别、不同站点中完成,由此会造成任务失败或等待状态。首先在舰员级进行排故和修复,若由于本级的故障检测和修理能力的制约不能完成该修复任务,需要将故障件送往中继级或基地级进行修复。换件修理中,在指定维修站点对失效单元进行拆卸,并根据单元类型确定报废还是修理,以及在哪个维修站点进行修理。假设在执行任务场景S2中,舰炮出现机电故障,经故障检测出现两个故障件,此后判断故障件是直接维修还是送修。记对故障件1进行直接换件的过程为实例R20,对故障件2的送修实例记为R21。记任务规定时间为t1,如总维修时间大于t1,则任务失败,进入任务结束场景。上述修复性过程如图4所示。
由于舰炮保障系统及维修保障过程十分复杂,利用基本Petri网进行描述与模型验证时,存在无输入和输出、状态空间爆炸等问题。对象Petri网(OOPN)技术将对象作为建模的基本模块,增强了基本Petri网的语义描述能力,对位置、转移和令牌等元素进行了扩充,增加了对象、输入端口、输出端口和开关四类元素,很好地解决了基本Petri网应用于复杂系统所面临的问题[8]。因此,以下拟将基于eBT 的舰炮维修保障过程模型转化为OOPN 模型,以对象为单位进行舰炮维修保障过程模型的验证。
OOPN模型的基本单位是对象,因此,可以将任务场景中舰炮维修过程的每个实例视为一个对象,每个场景中所有实例对象组合而成的父对象即对应于该场景。然后再依次将场景对应的父对象与其他场景中的实例对象进行组合,按照这个过程,最后即可实现整个维修保障过程到OOPN模型的转化。
以单场景实例Rij=(Staij,Eij,Conij,Actij,Reij)对应的eBT 模型为基本转化单元,对实例中的各个元素分别进行转化:
1)将单个场景中每个实例的eBT 模型转换为一个对象。对场景Si中的每个实例Rij对应的行为树创建对象Objij,则场景Si对应的父对象为Obji=Obji∪{Objij},OOPN 中 所 有 对 象 的 集 合Objs为Objs=Objs∪{Obji}。
2)将实例中的系统状态单元转换为位置。将状态集Staij中的每个状态Staijk转换为对象Objij的一个位置Sta_pijk。
3)将输入事件与输出事件状态单元对应转换为输入端口、输出端口与着色令牌。实例Rij中的输入事件与输出事件状态相当于实例对应的对象间互通信息的状态。在OOPN 中,通常用着色令牌作为信息传递的方式。因此,将实例行为树中的任意输入事件状态单元In_eijk对应转换为对象输入端口In_poijk和 着 色 令 牌In_ctijk,输 出 事 件 状 态 单 元Out_eijk对应转换为对象输出端口Out_poijk和着色令牌Out_ctijk。
4)将内部事件状态转换为位置和着色令牌。将内部事件状态集Inner_eij中的每个内部事件状态Inner_eijk转换为对象的一个位置Inner_pijk和着色令 牌Inner_ctijk;
5)将条件判断中的(事件,参数)转换为(转移,位置,弧),表达式转换为(弧,转移)。对条件判断单元集Conij中的任意条件判断单元Conijk,事件Conijk-e与参数Conijk-Para可对应转换为对象中的转移Con_tijk、位置Con_Pijk及由转移与位置构成的弧Con_aijk,将 表 达 式Conijk-exps转 换 为 弧Con_aijk和转 移Con_tijk。
6)将活动状态单元转换为位置、转移与弧。转移是Petri网中的活动表现,转移是在位置基础上进行的,因此将活动集Actij的任意活动构件Actijk转换为位置Act_pijk、转移Act_tijk与弧Act_aijk,且有
7)对eBT中各组成单元的关系进行转换。如系统状态与输入事件状态之间的关系Reij(Staij,In_eij)的转换方法为:将系统状态Staij转换为位置pij,输入事件状态In_eij转换为输入端口In_poij与着 色 令 牌In_ctij,关 系Reij(Staij,In_eij)转 换 为弧aij。
将单个场景中每个实例的eBT 转换为对应的基本对象后,根据实例之间的关系确定各个基本对象之间的联系,再依据对象输入、输出端口之间的联系将基本对象集进行组合,从而得到每个场景对应的OOPN 模型。需要注意的是:在对实例间的OOPN 进行组合时,由于实例eBT 集成时集成点的单元在两个实例eBT 中重复出现,因此,组合OOPN 模型时需删除组合点重复的节点。
行为树的集成过程为:首先查找一棵行为树的根节点出现在其他行为树中的位置,然后在此位置将两棵行为树集成起来,依此过程得到最终的集成行为树[9]。将单个任务场景中实例的子维修保障过程转化为对应的子eBT 模型后,每个实例的集成eBT 模型可以由实例中所包含的子eBT 集成得出,各任务场景的集成过程类似。由此,相同的维修保障实例eBT 模型可以实现重用。按照上节中提出的模型转换方法,将集成eBT 中的各个单元及其关系依次进行转换、组合并去除重复节点,得到如图5所示的OOPN 模型。
OOPN 模型的可执行性是指OOPN 能够顺利地使每个转移都发生,即令牌从每个节点的输入端口流到每个节点的输出端口[10]。如OOPN 模型可执行,则该模型描述的行为是一致的,如果模型中有转移不能发生,则该转移对应的行为存在一致性冲突。因此,利用OOPN 模型的可执行性进行任务场景下维修保障行为一致性验证的主要过程与方法为:
1)根据场景eBT 提取场景中的事件序列与活动序列。
2)设置OOPN 模型的事件为任务场景集S中的单个场景Si中实例Rij的事件集合Eij中的每个事件In_eijk、Out_eijk与Inner_eijk。
3)通过设置OOPN 模型中位置的令牌来设置OOPN 模型在各个场景下的初始状态。
4)最后执行OOPN 模型,验证模型是否可执行,并得出模型执行的活动序列。
笔者依据舰炮使命任务的特点,应用场景技术对舰炮的使命任务进行描述,一方面有利于各使命任务场景的具体任务分析及其相互逻辑关系的表示,另一方面能很好地获取并分析各个任务场景中的保障需求,从而明确场景中相关的维修保障过程。通过对适用于舰炮维修保障过程建模需求的常用建模方法的利弊对比分析,采用了由基本BT改进的eBT 方法与OOPN 方法相结合的组合建模方法,对每个任务场景下对应的维修保障过程中的活动、事件、决策及在保障系统中所表述的逻辑、规则和约束等进行清晰地描述,如此可以很好地反映其中各实体行为的交互、事件状态的改变、信息的交换,促进了对复杂的舰炮保障系统描述复杂性的控制,保证了保障需求描述的完整性与准确性;此外,相对于其他单一建模方法,笔者提出的组合建模方法在实现模型的重用性、保障需求的可追溯性及形式化的自动模拟验证方面更有优势。
(References)
[1]魏勇,徐廷学,顾钧元,等.某型舰炮保障性参数仿真评价研究[J].舰船科学技术,2010,32(3):136-139.WEI Yong,XU Tingxue,GU Junyuan,et al.Research of supportability parameters simulating evaluation for one-type naval gun[J].Ship Science and Technology,2010,32(3):136-139.(in Chinese)
[2]陈中育.基于场景的系统行为建模和组合研究[D].上海:上海大学,2011.CHEN Zhongyu.Research on scenario-based system behavior modeling and composition[D].Shanghai:Shanghai University,2011.(in Chinese)
[3]刘大东,孙朝江.水面舰艇舰炮武器综合保障发展探讨[J].兵器试验,2012,(1):49-50.LIU Dadong,SUN Chaojiang.Discussion on the integrated support development of surface-ship shipborne gun weapon system[J].Ordnance Test,2012,(1):49-50.(in Chinese)
[4]王维平.离散事件系统建模与仿真[M].北京:科学出版社,2007.WANG Weiping.Discrete event system modeling and simulation[M].Beijing:Science Press,2007.(in Chinese)
[5]孙宝琛,贾希胜,程中华,等.战时装备保障过程建模仿真研究[J].指挥控制与仿真,2012,34(2):97-100.SUN Baochen,JIA Xisheng,CHENG Zhonghua,et al.Study on equipment support process modeling and simulation in wartime[J].Command Control &Simulation,2012,34(2):97-100.(in Chinese)
[6]DUGGEN E W,REICHGELT H.Measuring information systems delivery quality[M].London:Ideal Group Publishing,2006:90-111.
[7]DROMEY R G.From requirements to design:formalizing the key steps[C]∥First International Conference on Software Engineering and Formal Methods.Brisbane:IEEE Computer Society Press,2003:2-11.
[8]舒振,陈洪辉,罗雪山.基于对象Petri网的军事信息服务组合与验证方法[J].系统工程与电子技术,2011,33(7):1558-1564.SHU Zhen,CHEN Honghui,LUO Xueshan.Military information service composition and validation method based on object Petri net[J].Systems Engineering and Electronics,2011,33(7):1558-1564.(in Chinese)
[9]DROMEY R G.Genetic software engineering simplifying design using requirements integration[C]∥Conference on Complex and Dynamic Systems Architecture.Brisbane:IEEE Computer Society Press,2001:1-6.
[10]丁泽柳.C4ISR 体系结构动态行为一致性验证方法研究[D].长沙:国防科学技术大学,2007.DING Zeliu.Research on the method of C4ISR architecture dynamic behavior consistency verification[D].Changsha:National University of Defense Technology,2007.(in Chinese)