中国指挥与控制学会会刊 
需求确定作为系统工程的“需求工程”,在系统工程中扮演解决方案的最初始角色[1],现在武器系统工程的研究多从确定的需求规格说明开始,极少追溯确定需求的过程,导致需求确定阶段被忽视[2]。现在典型的需求确定方法技术有结构化,面向对象,面向目标,基于形式化技术[3]。结构化技术自顶向下,逐层分解来定义需求,强调功能聚集及耦合原则,但开发周期长,可维护性和跟踪性差;面向对象技术从现有系统组成问题分解,模块性、可重用性及可维护性好,但缺乏层次,难以研制新系统;面向目标技术对目标进行分解,粗粒度大,细节表现不足;基于形式化技术以数学方法描述目标系统性质,用数学符号、法则对系统结构、行为进行结合分析推理,但实现复杂,表达能力弱。以上方法的典型框架和建模语言有IDEF,UML和SysML。从军事需求领域出发,武器系统需求须满足对作战想定,作战任务和作战节点的支持,具有层次性,而UML本身不提供层次建模功能;IDEF等结构化分析方法,可层次分析作战领域相关要素,但描述机制复杂,不便于理解和沟通;SysML结构与行为分离表示方法不利于建模人员从整体上构建模型,同时在实践中存在多元素重复定义,语义容易出现一致性错误问题。同时以上建模方法较少以军事为背景,说明其在军事想定中具体关键环节的作用,无法从武器系统利益相关者的设想或预期特定目标来理解和描述系统[4],导致武器系统需求上极易发生变更或者需求难以正确反映系统特征,不得不进行系统工程重设计,使得技术难度加大,投入资金增多,质量与可靠性要求难以保证、研制风险和管理难度再度提高[5-6],为此将使武器系统设计和使用阶段付出极大的代价[7]。
本文以OPM为建模框架,从军事威胁背景出发,分析了面向威胁的作战概念对武器系统需求确定的优势和作战概念对需求确定的重要性,提出基于作战概念的武器系统需求确定研究方法,支持武器系统的需求确定,开发简洁,层次性强,表达性好。最后以无人机反导防御系统对需求确定方法进行演示验证说明。
1 相关概念
1.1 作战概念与需求确定
作战概念(Concept of Operations,简称ConOps)是用户对目标系统的描述性说明,向利益相关者传达系统的定性或定量特征[8]。其广泛应用于军事、政府和服务领域,在美军联合作战中,国防部对作战概念的定义是:清晰且准确地表达联合力量指挥官作战在有限资源下实现目标打击的口头或图形化实施方案[9-10]。在系统工程领域里,作战概念的延伸是需求确定实施步骤,在需求确定的驱动下作战概念包含以下步骤[11⇓-13]:1) 声明系统问题的应用范围,明确系统的预期目标和最终状态;2) 构想系统整体的解决方案,描述系统解决方案在未来环境中的运行过程;3) 确认系统交互,包括系统与环境、子系统、组成部分、功能组件和物理结构之间的交互。所以,作战概念是武器系统需求确定具体实施方案,是需求确定落地的指导手册,有助于声明系统的目的或目标,理清影响系统的策略和政策约束,明确责任与授权,掌握参与者及利益相关者之间的互动,指导现场系统的具体操作过程[14],是武器系统工程领域是否取得成功的关键因素[15]。
1.2 面向威胁的武器系统作战概念
1.3 基于OPM建模框架的选择
本文提出的面向威胁的作战概念武器系统工程建模语言需满足以下内容:1) 建模语言支持对模型的构建、扩展和不断地改进完善;2) 支持威胁处置过程中定性分析,推演仿真和逻辑校验;3) 保持语义的一致性;4) 系统复杂性管理。IDEF,UML和SysML语言优缺点在引言已作相关分析,此处不再赘述。
为支撑相应的方法要求,同时满足信息和知识语言的一致性逻辑验证,系统的复杂性管理等,基于以上要求和以下相关优点,本文选择Object-Process Methodology[18](对象过程方法论,简称OPM)作为面向威胁的作战概念武器系统工程建模方法:
1) OPM使用单一的图标解决不同层次的分类,统一静态结构和动态程序,有效地减少高度复杂的系统团簇;
2) 通过将系统随层展开成自相似的OPDS,并通过递归还原,有效地解决系统的复杂性管理;
3) OPM使得能够延伸到系统模型的核心,同时保持与模型核心的充分协调和产生新模型的能力。通用的多用途模型或模式可以被实例化,适用于各类特定的系统问题[19];
4) OPM是ISO公开可用规范(PAS),即ISO 19450国际标准,是基于模型系统工程的建模标准[20];
5) Sharon和Dori 在2009年证明OPM是优胜于UML,XUML,以及SysML建模语言[21]。
2 OPM概念与建模
2.1 OPM介绍
OPM(Object-Process Methodology)对象过程方法论是Dori在2002年提出的通用建模方法[22],兼具图形表达和文字说明,符合标准(ISO19450)的系统工程建模框架[23]。OPM 以简单直观的标识方法,集成面向对象和面向过程建模范式于同一参考框架,基于同一视图建立系统结构模型和行为模型,将系统的静态结构和动态行为有机结合,支持系统工程从需求分析到系统集成的系统工程全周期建模。同时,在系统模型顶层添加模型,而不破坏系统核心框架[24],故而在OPM上可以很自然地添加威胁应对模型层组件,而保障多层模型的协调性和一致性,从而通过对细节层次的分解处理复杂性,保障需求的快捷响应[21]。最后,OPM支持模型推演,可以对系统行为进行校验和验证。
2.2 OPM建模元素
OPM建模本体分为实体(Entity)和链接(Link),如图1 所示。实体是OPM系统建模的基本模块,对象(Object)和过程(Process)是OPM的主要实体。对象描述系统的物理和信息,支持系统实体或者环境实体,即信息实体或物理实体的设计;过程描述对象之间的迁移转变。过程可以生成、消耗对象,也可以改变对象的状态。状态(State)是对象的属性,作为实体附属于对象。链接分为结构性链接和过程性链接。结构性链接描述系统内实体之间静态的、与时间无关的关系,过程性链接则连接实体间对象(过程和状态),描述系统的行为。与面向对象方法不同,OPM的过程不是封装在特定的对象类中。独立的过程建模允许在一个过程中激活或改变多个对象。
系统行为在OPM中有3种表现方式,并采用不同的过程性链接表示,分别是:1)迁移链接,过程转变对象,即过程中生成、消耗对象或改变对象的状态;2)主体链接,对象执行过程而不被过程所迁移,如对象启动或终止某个过程;3)事件链接,实体满足某些条件后触发事件调用相应的过程。OPM的事件类型支持状态进入、状态迁移、状态超时、过程终止、过程超时等内部事件,也支持外部环境触发的事件。
2.3 OPM建模模型
OPM提供了图形和文本两种在语义上等价的表达方式,分别是OPD(Object-Process Diagram)和OPL(Object-Process Language),如图2 所示。过程对象图可以在不同粒度层次上描述表示过程对象。每个OPM建模元素都对应到一个OPD符号和OPL中明确的语义,OPD的语法用于定义实体之间正确和一致的链接关系,OPL是模型文本描述语言,与OPD元素一一对应,在模型可视化图形的编辑时自动产生,且OPL接近于自然语言,易于理解和交流。
同时,OPM模型通过组织分层对象过程图(OPDS)的三个机制来降低系统的复杂性:
1)对事件的结构层次的折叠与展开(对象为主);
2)展开流入或流出事件的内在细节(过程为主);
3)对象状态的激活与未激活。
对上一层对象或过程的展开可以得到下一层OPD,而对下一层OPD的折叠可以得到上一层的对象或过程。
3 基于OPM作战概念的武器系统需求确定方法模型
本文以OPM为模型框架构建面向威胁作战概念的武器系统需求确定方法模型。该模型可以用于指导应用案例的开发,可适用于大多数武器系统的需求确定。
3.1 确定需求框架
武器系统的需求框架在于确定武器系统组件(或子系统)的结构和功能,功能过程包括消耗的输入、产生的输出和支撑资源集。武器系统是包含若干个子系统,每个耦合的子系统有相应的功能,而整个武器系统的功能不仅仅是其组成子系统对应的功能的叠加,武器系统的功能集具有涌现性,在需求确定中要体现出功能集,相应需求框架如图3 所示。
3.2 面向威胁的作战概念武器系统需求确定模型
从面向威胁出发,须在需求框架里创建威胁影响,以及面向威胁的作战概念,作战概念形成作战概念ConOps文档驱动确定需求功能进行,确定需求功能带动相应的支撑资源集结构的生成,也包括输入需求、输出需求。如图4 便是面向威胁作战概念的武器系统需求确定模型。由图可知,虚线框内的部分是需求框架,虚线框外部是面向威胁作战概念的武器系统需求确定方法模型,此模型中包含子系统需求,作战概念,确定需求功能这些变量。这些变量是抽象化的概念体,可以根据具体想定对应的具体实例。作战概念和确定需求功能,其中作战概念和确定需求功能可以在同一模型下展开,且同时表示为多种不同实例。类似的子系统需求及其内部组件也可以在模型展开中添加,在保持模型一致性的前提下扩展模型的表达,对添加的需求灵活处置。
本模型的最终需求确定包括确定需求功能,资源集需求。输出需求和输出需求可以根据具体作战概念确定,但资源集需求相对固定,对于武器系统可以认为是物理实体结构。为方便读者理解本模型,与OPD图相对应的OPL自然语言描述如下:
武器系统具备功能集等属性。
功能集包括功能。
武器系统包括子系统。
子系统具备功能等属性。
功能需要资源集。
功能消耗输入。
功能生成输出。
子系统需求是子系统。
子系统需求具备确定需求功能等属性。
确定需求功能是功能。
确定需求功能需要资源集需求。
确定需求功能生成输出需求。
输出需求是输出。
资源集需求是资源集。
作战概念影响威胁与作战概念CONOPS。
本方法模型是顶层抽象模型,需要对抽象对象和过程实例化,通过层次打开对象和过程的内部细节,继而剖析作战概念下的内部系统之间和内部系统与外部环境之间的交互,从而确定系统的功能和结构需求。
4 案例分析
4.1 案例背景
本文将展示面向威胁处置作战概念的武器系统需求确定方法模型实例化下的反导防御系统无人战斗机功能和结构确定。2011年2月,美国格鲁曼公司为海军研制X-47B无人战斗机首飞成功,因其滞空时间长、作战半径覆盖范围广、载弹量大且具备隐身功能而备受关注[25]。为积极应对伊朗和朝鲜远程弹道导弹的威胁,保证美国本土和欧洲北部和西部地区安全,美国海军在保证对地打击能力前提下,正在积极谈论扩展X-47B拦截导弹的需求可能性,即在无人战斗机上配置新的功能组件,同时与其他原功能设计保持一致性,部署配置NCADE导弹(Network Centric Airborne Defense Element,网络中心机载防御单元,空射型反导导弹)来及时避免或抵消弹道导弹的威胁[26],具体拦截方式如图9 。
4.2 模型设计
本文从导弹防御领域寻求需求解决方案和设计,使之能够自我侦测,确定威胁,然后做出以下可用的作战概念需求:机动规避导弹;反导武器如导弹NCADE或者激光炮;通过诱骗散射或无线电信号传输干扰弹道导弹,使之混乱。首先根据需求框架,确定系统架构和基本功能,如图6 虚线框所示。从图中可知武器系统的顶层结构功能需求模型,包括武器系统所要确定的子系统结构及其相对应的需求功能。本案例的核心功能是弹道导弹防御,为了完成结构功能需求视图,添加面向弹道导弹威胁的作战想定,通过作战概念驱动需求功能确定,本方法将对作战概念逐步展开防御系统防御过程中的各部分模块及其对应功能的需求确定。
作战概念展开如图7 所示。此作战概念是防御系统与外部导弹之间的交互关系,无人机的反导防御是作战防御和导弹拦截的组成过程。弹道导弹的发射和飞行是外部实体过程,然后通过无人机防御系统的拦截行动和成功击毁(此过程消耗拦截导弹也消耗弹道导弹),故为确定无人机防御系统需求,需进一步展开作战防御。
作战防御展开过程如图8 所示。可以发现,为支撑作战防御过程,反导防御需要有相应的功能支持,如实施导弹侦察行动,则反导防御系统需要具备导弹侦察功能,图8 中的表示的是导弹侦察是导弹侦察行动的组成部分,同时从作战概念出发,需要有评估功能来确定导弹是否被侦察到,打击概率是否支持实施预拦截,最后根据拦截的可行性来做出拦截行动。从图8 中可得相应功能需求就有导弹侦察,导弹追踪,打击评估和实施预拦截。本方法支持对每一个功能模块再次展开,进一步观察系统功能的内部细节,本案例为确定相应的功能和结构模块需求,展开层次止于此即可。
对本模型初始化模型参数后,启动推演功能可以观察作战概念的动态行为、资源消耗、属性的变化和作战概念的推演过程,建模人员可以直观地对需求进行全面的评估,图9 是本方法面向威胁作战防御的动态截图,图中下方的元素生命周期图显示了模块单元和威胁应对的过程进度。
在本案例中,经过推演的初步验证和校核,作战概念通过作战概念CONOPS影响反导防御功能的确定,其对应生成反导防御及其组成功能及其相应的结构模块如图10 所示。
其中,反导防御系统的结构模块有雷达模块,指控中心模块,发射模块和拦截模块,反导防御的功能组成模块有导弹侦察,导弹追踪,导弹毁伤评估,实施预拦截,触发发射拦截,发射拦截,捕获导弹和拦截导弹,由此武器系统的功能和结构需求得以确定。需要再加说明的是:对应的输入需求为系统识别信号,输出需求为驱动模块功能的信号,本文暂不关注该细节。
本案例是本方法模型的实例化,这个模型涉及威胁及其相应的识别追踪打击等功能,多项功能对应多项结构模块需求的生成,需求的满足使得系统在使用过程中能灵活且更好地选择相应措施以规避威胁或消除威胁。
5 结束语
武器系统的研制本身就是一项复杂的系统工程,而系统需求往往决定工程的成败。面向威胁的作战概念建模,使得武器系统在面对威胁的处置上实现相应的功能模块的需求配置。为此,本文以OPM为模型框架构建面向威胁处置作战概念的武器系统需求确定方法模型,将系统的需求确定通过作战概念推演确定。本方法使系统设计者从作战概念角度确定武器系统的需求配置情况,满足系统的设计目标。