战场信息交换语言统一开发框架

赵鑫业 王义涛 王超 王珏

1.海军大连舰艇学院辽宁大连116018

指挥与控制(Command and Control,C2)系统之间的互联、互通、互操作,与实际传感器和武器系统的无缝链接,与仿真模拟系统的一体化操作,乃至无歧义地指挥自主无人系统(Autonomous Systems 或Robotic Systems),不仅要求作战系统中各元素连接成网络,更需要它们以一种相互理解的方式协同工作.这就需要在不同要素、各军兵种的信息系统之间,清晰无异地表达、传递军事计划和命令[1].在国内,信息交换的标准化工作已经开展多年[2−6],从各个军兵种到联合作战层面,但是距离建立统一的、面向联合作战的作战互操作标准还有很长的路要走.国际上通用的C-BML、MSDL 等标准,已经在多次联合作战及兵棋推演仿真中得到了成功应用.

战场信息交换语言(Battlefiel Information Exchange Language,BIEL)旨在为我军C2 系统、仿真系统和自主无人系统之间的标准化信息交换提供支持.BIEL 作为一个互操作性标准,可以极大地方便军事想定的准备和执行,以支持相关军事活动(例如:训练,行动支持,概念的开发和实验).BIEL 的初步试用研究已经显示出以下优点:1)减少计划或实验的准备时间.2)增加培训或实验环境的现实逼真度.3)降低由所需模拟器操作员人数的减少所导致的成本.

随着各类面向作战的互操作标准化语言的不断增多,发现这些语言有一个共同点,就是大部分的语言虽说有着各自的业务需求,但其基础功能是类似的,比如内容模型、交互式协议等.系统开发人员每次在设计及开发互操作语言时,都需要重复开发这些基础功能.这样既效率低,其开发后的维护成本也高.如果有一套基础通用的开发框架,将这些语言都用到的功能统一起来,将大大加快语言开发的速度和开发强度.鉴于此原因,开发部建立了BIEL 统一开发框架.BIEL 统一开发框架就是集合以及以往国内外各类互操作语言开发的经验,将开发过程中的一些通用的、可复用的功能模块,整合起来,以内容模型、消息框架、交互式协议和服务组件为核心,按照从需求、参考体系框架、形式化规范、规范指导参考实现的设计思路,形成一个统一的开发框架,将BIEL 的设计和开发建立在这个统一开发平台之上.使设计及开发人员能够脱离重复劳动,高效率开发出BIEL,并为其他互操作语言的框架性开发提供有益借鉴.

1 BIEL 概述

BIEL 用于无歧义地表示战场环境下系统(或机器)之间的军事信息通信.首先介绍一下BIEL 的语法(grammar).语法是一系列规则—用于说明对于一种特定语言,如何构建有效的句子和表达式.BIEL表达式是基于“谁,干什么,哪里,什么时间,为什么(Who,What,Where,When,Why,5W)” 的结构,便于组织和规划行动单元.BIEL 遵循了以上有关5W 的基本定义.一个简单的用于表示任务的图形化BIEL示例,如图1所示.

从互操作性分层来看,概念互操作等级模型(The Levels of Conceptual Interoperability Model,LCIM)认为系统之间的互操作性从不同程度上看,可以分为5 个层次[6−7]:即技术互操作性、语法可操作性、语义可操作性、语用互操作性、动态可操作性和概念互操作性.对照以上5 个层次,参照CBML,给出了对应的层次化BIEL,即:条令[8−9]、表达[10−13]、协议[14−15]、本体[16−19]和语法[10,12−15].

另外,开发BIEL 面临以下诸多的挑战:标准的复杂性,方法的复杂性,协调制定(或使用)标准的不同部门之间分歧能力的不足,不充分的资源,缺乏清晰的范围和需求,不确定的和不充分的标准制定或使用方.

2 BIEL 统一开发框架概述

鉴于在以往互操作标准(例如C-BML)发展过程中碰到的困难,以及为了使BIEL 标准的开发变得更加有序和有效,在借鉴C-BML 标准开发框架(Standards Development Framework,SDF)[7−8,23]的基础上,提出BIEL 统一开发框架.这里提出统一开发框架用于指导BIEL 的各个开发过程及促进BIEL 标准产品的开发,其基本目标是:提出一种开发方法,以受控、可重复的方式,基于一组可追溯的需求来发展BIEL 标准,并在不牺牲互操作性的前提下保证扩展性.统一开发框架组织BIEL 的各个方面,在功能和范围方面从不同的抽象层次上建立分离的关注点.期望通过这个框架能够方便地交流、解决需求或理解的分歧,为恰当地界定和组织BIEL 标准制定活动提供帮助.BIEL 统一开发框架有很强的适应性和通用性,可以作为BIEL 开发的一个通用框架.

BIEL 统一开发框架建立了在体系结构框架上的一致性:从需求到参考框架,到实现技术的架构;最后到程序相关的架构和参考实现.BIEL 标准设计的初衷是与BIEL 兼容的系统可以嵌入多种作战环境下(例如不同军兵种的指挥信息系统).因此,BIEL统一开发框架将提供对已有服务、程序等的扩展机制.参照C-BML 标准开发框架,其与北约体系结构框架(NATO Architecture Framework,NAF)、美国国防部体系结构框架(Department of Defense Architecture Framework,DoDAF)、英国国防部体系结构框架(Ministry of Defense Architecture Framework,MoDAF)

等体系结构框架(Architectural Frameworks,AF)保持一致,C-BML 标准开发框架可以描述基于C-BML的解决方案是如何支持作战用例的.

与C-BML 标准开发框架类似,BIEL 统一开发框架包含如下开发活动:1)BIEL 需求管理.2)BIEL概念、逻辑和物理模型的表示.3)BIEL 语法的定义.4)消息传输和BIEL 服务的定义.5)一系列BIEL 用例的创建.6)BIEL 与其他标准的通信.

2.1 BIEL 统一开发框架关键特点

BIEL 统一开发框架包含以下关键的特点[7]:

1)需求驱动.BIEL 需要满足许多貌似矛盾的需求.例如,BIEL 必须要足够通用以支持多种原有系统,但又要满足扩展性的要求以适应多种环境.为了达到这个目标,框架必须能够获取多种需求并允许开发、追踪、校验和其他需求管理活动.

2)可扩展性.根据需求的广度,BIEL 必须能够在通用性和特定解决方案之间寻求一种相对的平衡.执行程序能够在使用过程中获取BIEL,并做出领域相关的扩展以适应其领域.因此,统一开发框架使用扩展的设计范式—定义BIEL 的核心并为创建具体应用领域扩展提供指导.当然,这些扩展也包含BIEL.

图1 用于示例5W 的图形化BIEL 示例Fig.1 A Graphical BIEL example for 5W

3)可维护性.BIEL 将支持一系列之前的标准、系统和通信网络.为了创建一个包容过去的、当前的、未来的技术环境,统一开发框架使用分层的方法用来描述概念相关的、执行相关的、技术相关的不同方面.目的是解决方案能够同时保证对于技术改变的包容性和对具体相关执行设计的支持.

4)阶段性开发.BIEL 的开发将是循环迭代无止境的.为了达到这个目的,统一开发框架支持一种阶段性的、用例驱动的、能力驱动的开发方法.统一开发框架使用一种全谱系架构性的视角用于定义产品.

5)建立与其他标准的适配性接口.各个军兵种已有的互操作标准或规范与BIEL 在概念和技术上有许多重叠.因此,采用可兼容的XML 模式文件用于确定BIEL 中信息交换机制.隔离关心点将清晰地区分系统或标准的哪些方面需要和BIEL 结合.

2.2 BIEL 的开发目标

必须减少BIEL 使用的障碍.BIEL 标准必须具有明确的目标,必须易于理解和解释,必须具有可扩展性和灵活性,并且必须能够良好地与传统的解决方案相融合.对BIEL 的目的、范围、应用和角色之间更明确的表达有助于改进BIEL 的开发、评估、使用和维护.BIEL 统一开发框架旨在将所有这些问题组织到一个框架中,促进讨论以解决矛盾,并有助于划定确定的范围及组织标准的开发活动.

2.3 BIEL 开发过程

BIEL 的开发过程将遵照BIEL 统一开发框架的递进式分层结构(图2).目前可用的技术为标准开发活动提供了自动化的机会,其提供了生成规范产品的方式而不是手工编辑的方式,手工编辑的方式对于产品开发和随后的产品修订来说可能是耗时且容易出错的.随着标准的发展,自动化技术已经成功地应用于标准产品的开发,使用UML 建模工具—EA(Enterprise Architect)创建BIEL 统一开发框架[7,23].需求包使用UML 的需求配置文件扩展,而Ontology工具栏允许定义、导入和导出OWL 本体元素.为了与MDA 保持一致,EA 支持各种模型表示形式之间的转换:例如,可以将以OWL 本体表示的内容模型转换为XML 模式文件;另外,还可以自动生成网页或形式化文档(有利于更广泛地共享模型,而不需要熟悉建模工具的使用).另外,也可以使用EA 定义BIEL 逻辑数据模型,并派生出平台特定模型(如XML 模式文件).

2.4 使用统一开发框架扩展BIEL

与任何产品开发一样,确定产品范围和产品开发计划对于确保产品的及时可用性和实用性至关重要.普遍担心的是,需求和实施方案的多样性很大程度上取决于大量的技术选择以及广泛的、不同的开发系统群体.另一个相关的问题是确保统一开发框架的5 个层面都具有灵活性和可扩展性.领域扩展和变更提案将能够作为形式化规范的应用程序来制定,形式化规范将提供如何应用该标准的具体示例以及为什么需要进行更改.

统一开发框架旨在通过提供扩展框架各部分的手段来支持多个具体领域的需求.作为本体模型,核心内容模型可以扩展领域相关的元素.消息框架可以应用于整个战术消息集,其结果可以在领域内或跨领域重用.类似地,交互协议定义也可以被分类,特别是当它涉及任务线程和消息线程时.服务规范可能会导致服务实现,也可能被共享为API 和SDK.此外,由于BIEL 统一开发框架规范了这些相关的扩展,因此,统一开发框架是确保所有与BIEL相关的扩展、分类和软件以一致的方式表达的通用框架[7,22,24].

3 BIEL 统一开发框架组件层

通过参考及借鉴C-BML 标准开发框架[20−21],BIEL 统一开发框架定义了5 个组件层,以概念和规范的形式对BIEL 产品进行分层,如图2所示,包括需求(Requirement)、参考体系结构(Reference Architecture,RA)、标准化规范(Normative Specification NS)、规范指导(Specificatio Guidance,SG)、参考实现(Reference Implementation,RI),这5 个组件层区分了BIEL 目标产品中概念和规范的不同层级.

图2 BIEL 统一开发框架结构图Fig.2 Structure diagram of a unifie development framework for BIEL

1)需求:以具体任务、作战活动和信息流形式定义的作战用例.

2)参考体系结构:用于支持领域数据模型、信息框架、交互协议和抽象服务组件的概念层组织.这部分内容随着需求逐步进化.

3)标准化规范:BIEL 形式化规范由具体实现相关的细节构成.形式化规范在结构、多执行程序集成等方面依赖于参考架构.

4)规范指导:对于形式化规范具体的指导性附录,可能包括推荐相关技术,执行示例,标准的示例性扩展,其他非强制性说明(也是规范的一部分)等.

5)参考实现:开发的软件程序用于验证规范并展示其可执行性.参考实现的目的是保证BIEL 开发的完备性.

接下来将详细讲述统一开发框架的每一个层次.需要注意的是,每一层次建立在前一层次的基础之上.

3.1 需求

BIEL 统一开发框架的需求层,通过创建和选择作战用例来推动BIEL 的发展[24−25].互操作标准的开发通过定义一种公共的交换信息的方式来指导信息系统之间的通信.标准事实上由一组形式化产品组成,产品按照每个系统的需求指定了异构系统成功集成和交互的技术细节和示例.确定和管理这些需求是成功建立标准的关键,保证需求能够最终被采用并满足标准使用相关方的期望.将系统工程方法应用于互操作性标准开发中的需求工程阶段,目的是确保标准的成功开发和应用[24].

标准是为产品、过程、程序、实践和方法建立工程和技术需求的文档,而标准又被权威组织所颁布或被一致认可并采用[25].标准开发组织发布产品(例如技术性规范或其他支持性文档)用于指导或约束系统开发、集成、维护及系统生命周期的其他方面.产品不是终端用户的系统,但是提供了有关终端用户系统必须拥有的特征和必须满足的需求的保证.

3.2 参考体系结构

统一开发框架中最核心的内容在RA 中,如图3所示,参考框架定义了数据的、消息的、交互协议的、服务的核心模型,每一部分程序都是可扩展的[21].

下面详细介绍参考框架中的每一个组成部分.

3.2.1 内容模型

参考框架的第1 个组成部分是内容模型(Content Model,CM),如图4所示.内容模型由核心数据模型,又称为逻辑数据模型(Logical Data Model,LDM)和核心数据扩展模型组成,用于联合作战、多军种的、服务的、系统相关程序的规范指导组成.BIEL LDM 专注于描述基本数据元素和关系.将MDA 用于开发BIEL LDM,描述LDM 的结构、类、关系,并讨论扩展LDM 用于专有领域并生成核心数据扩展模型的机制.

图3 BIEL 参考框架Fig.3 BIEL reference architecture

核心内容模型是由Web 本体语言(Web Ontology Language,OWL)定义的领域本体,使用UML 进行管理—主要以利用UML 代码生成能力.通过使用OWL,内容模型可以从可扩展性特性中受益.核心内容模型仅限于对BIEL 最重要的要素,并被分为3组:

1)“5W”的对象.核心内容模型泛化了常见的本体论元素的概念:对于“Who”的实体(Entity);为了“What”的事件(Event)和行动(Action);对于“Where”的空间区域;对于“When”的时间区域;用于解决的“Why”.

2)属性:用于描述一般对象的状态、功能、关系或任何方面.

3)通信行为是通信理论的重要组成部分.通信行为是行为类型,包括断言(报告)、委托(回复)、声明(控制措施或任务组织声明)和指令(命令和请求).通信行为理论解释了其他通信行为,但这些不适用于BIEL.

核心内容模型的这一部分借鉴了IEEE 物理智能代理基础(Foundation for Physical Intelligent Agents,FIPA)标准和用于统一通信本体(Communication Ontology,CO)的研究内容.

3.2.2 消息框架

消息框架(Message Framework,MF)定义了一个抽象的消息结构,该结构逻辑上区分了组成BIEL消息的元素:消息内容、消息元数据、传输元数据,如图5所示.在执行层,传输元数据被指定为消息头(Header),作为执行相关的传输信封体(Transport Envelope,TE)的一部分.传输信封体又封装了BIEL消息的其他部分(例如内容和元数据).消息框架同样定义了内容模型支持的信息如何被组织成可表达的形式,并与产生式规则(即BIEL 语法)保持一致.

图4 BIEL 内容模型:核心和扩展Fig.4 BIEL content model:core and extension

图5 消息框架Fig.5 BIEL message framework

根据一组规则和指导原则,消息框架指定一组用于构造消息的高级结构,从而为生成BIEL 消息提供一种一致的、标准化的方法.同时,它可以灵活地让用户针对其具体的领域特点建立表达式和消息.

3.2.3 交互协议

统一开发框架的交互协议(Interaction Protocols,IP)规定了系统之间信息传递规则.作战信息的交换很少限制为一条独立的消息,大部分的情况是,多条消息在多个执行者之间交互,而多条信息之间又相互依赖.例如,确认(Acknowledgment)消息可以在报告(Report)或请求(Request)之后.与通用任务上下文相关的交互消息被称为“消息线程(Message Threads,MT)”.交互协议提供了为BIEL 消息定义协议所必需的构造体,从而驱动对消息内容、消息元数据和系统实现的附加要求.在研究初期对协议的关注主要还在LICM 模型的技术互操作层次,如传输协议、数据交换协议等,随着研究的进展,这一关注集中到了语用互操作和动态互操作层次.

由于军兵种、兵力编成和应用的多样性,战术信息交换的许多方面在BIEL 中无法标准化.出于这个原因,统一开发框架没有规定一套标准的交互协议,而是定义了如何以结构化的形式获取交互协议.然后,标准使用方可以对交互协议进行编目、选择协议、确定哪些协议是兼容的,并最终在Agent 之间实现智能通信.

按照作战需求,作战信息的交换很少能由单个独立的消息完成,更多地是通过多个相互依赖的消息按照一定的交互关系来完成,比如在一个“报告”或“请示”消息之后,一般会有一个“应答”消息返回来.图6描述了一个“申请火力支援”的交互协议.该消息线程发生在前向观察者和火力打击指挥中心之间,并涉及一系列消息,每个消息指定一个通信行为,例如:请求、拒绝、同意、建议、接受等.实例中,消息交互发生在“前出侦察员”和“火力检定中心”之间,消息交互通过表达通信行为的一系列消息来完成.

BIEL 语用互操作和动态互操作层次上的协议,更多地与具体应用的状态与过程相关,要想在一个相对通用的语言里作出规定,需要将众多的交互过程分解,抽取出若干共性的、可组合的独立过程,再将它们协议化.和所有协议一样,为保证BIEL 协议的可靠性,特别是无人自主系统使用它们时的可靠性(如死锁问题),协议验证也是BIEL 协议工作的一项重要工作.与通信协议或其他协议一样,BIEL协议的验证也可以通过形式化方法进行,如有限状态机(Finite Automata,FA)、Petri 网、概率模型检验(Probabilistic Model Checking,PMC)等.

图6 BIEL 交互协议示例Fig.6 A example of BIEL interaction protocol

3.2.4 服务组件

BIEL 作为一套规范标准,用于C2 系统、仿真系统和自主无人系统之间的命令、计划、报告和请求等军事信息的标准化交换.BIEL 提供了一个通用的、标准化的方式,其中包含足够的表达性的词汇和语法来支持真实单元、仿真单元或自主无人单元之间的报告和任务的表示.为了应对技术独立性和协议不可知性,BIEL 标准规定了通过BIEL 服务使用不同传输机制进行BIEL 消息的实际传输,并制定了信息交换所需的信息元[6−7].

服务组件(Service Components,SC)部分旨在组织如何在BIEL 中定义服务接口.服务组件部分将为核心BIEL 服务定义一组有限的服务定义,但主要将指导具体领域以通用的方式定义领域相关的服务,可以对它们进行编目、重用、比较、组合等.注册、生产者、消费者、发布者和订阅者等服务端点需要与服务解决方案相一致.

3.3 形式化规范

统一开发框架的形式化规范层(Normative Specifications NS)将参考架构中的元素以正式的规范组合起来,然后可以将其应用于特定执行程序的定义,如图7所示.形式化规范允许将参考体系结构的视图应用于特定的信息交换标准,如SOAP/WSDL、RESTful Web 服务或XML 模式文件,以实现系统之间某种程度的互操作性.

图7 BIEL 模型和消息框架之间的关系Fig.7 Relationship of BIEL model and message framework

作为形式化规范的一部分,消息框架中定义的表达式和消息与内容模型(内容模型定义BIEL 消息是如何被使用者解释的)形成语义关联,如图8所示.内容模型和消息内容相分离的模式允许多种互补的消息模式,而不是强加一组规定的格式化的文本消息模板.内容与消息的解耦不再限制使用单个XML模式文件,因为多个可能的XML 模式文件可以在需要时以扩展的内容模型相关联.

在内容模型和消息框架中捕获的词汇和语法足以满足许多涉及简单消息线程(例如报告或确认)的BIEL 用例.但是,对于许多用例或任务线程,通常会交换和引用大量相关的消息.为了支持与这些消息线程相关的更复杂的信息流,需要更高要求的标准化.交互协议约束与特定任务线程(例如请求火力示例)相关的消息通信.交互协议指定对于给定的消息线程,消息如何与其他消息相关及依赖关系,并规定了BIEL 客户端在参与消息线程时必须符合的规则.

核心BIEL 服务满足两个不同的需求:1)为基本BIEL 消息操作提供标准接口.2)允许BIEL 客户端根据架构扩展定义自己的服务.最后,形式化规范层将包括核心BIEL 服务规范,服务规范以实现技术的形式提供协议相关的描述,如图9所示.对于网络服务(Web Services,WS),可能包括SOAP、REST、WebSockets 或SSE;对于仿真互操作协议,可能包括HLA、DIS 或TENA;对于消息传递,可能包括SMTP、AMQP、XMPP 或OMG-DDS.

3.4 规范指导

统一开发框架规范指导(Specificatio Guidance,SG)层列举出对内容模型和消息框架的示例性扩展.规范指导同样列举战术消息或系统相关的消息.规范指导层还可以说明如何使用BIEL 的可扩展性来制定战术消息或系统特定的消息.最后,规范指导层也可能会解决诸如与常用编程语言有关的技术特定问题.

3.5 参考实现

IR 层为原型实现、测试、验证和修改规范提供了可能.参考实现层虽然是BIEL 统一开发框架的最后一层,但这种实现为BIEL 的概念构想提供了验证[8].

4 BIEL 与C-BML 优劣对比

BIEL 与C-BML 的共同点为:1)具备与相应的系统间产生和消费统一数据的能力.2)技术层解决方案能够完全支持的交互协议.3)所有系统就符合语法层要求的术语集达成一致.4)共享术语含义并能够预知上下文.

BIEL 在C-BML 的基础上,统一了我军各个军兵种面向联合作战信息交换的数据含义和上下文定义,并进一步规范了对系统概念模型的同一理解(包括信息、进程、状态和行为).最重要的是,C-BML 主要是面向北约国家(尤其是美军)设计及开发的,虽然内容及关键技术值得借鉴,但并不适合直接的“拿来主义”,即插即用于我军的C2 系统与仿真系统的交互,而BIEL 为面向我军特色的军事领域的仿真标准,支持协调我军各军兵种仿真系统间的集成和互操作,对圆满完成新一代部队仿真系统(尤其是嵌入于C2 系统的仿真系统)、无人系统的研制建设任务,进而提高部队各级指挥员的指挥谋略训练水平,具有重大的理论和实践意义.

图8 BIEL 内容模型和消息框架之间的关系Fig.8 Relationship of BIEL content model and message framework

图9 BIEL 信息交换协议Fig.9 BIEL message exchange protocols

5 结论

设计BIEL 的初衷是为我军面向联合作战的C2系统、仿真系统、无人系统提供物理互操作性的解决方案,但是技术是不可避免地会发展的,使用标准的需求也将会发生变化.因此，这种解决方案必须灵活且易于修改和跟踪.BIEL 统一开发框架的设计以系统工程、需求工程和软件工程为依据,构建基于系统工程的BIEL 开发全生命周期整体解决方案,以满足标准化语言开发的工程技术需求.

BIEL 统一开发框架从逻辑层面对BIEL 数据、消息、服务、接口和行为方面进行了详细划分,其流程及分类方式可借鉴于其他标准的开发.而各个标准开发和应用部门越来越关注标准之间的相关性、兼容性和重用性.BIEL 统一开发框架为关联、重用和整合不同标准作出了一种有益的尝试.