中国指挥与控制学会会刊 
北约(NATO)各盟国多采用本国特定的军事信息系统,因此亟须统一互操作标准以实现联合作战中无歧义的信息交换。以美军为代表的北约通过规范化的作战筹划、决策、指挥标准、机制与流程以及军事信息系统,提高作战指挥效率与能力,为实施多国联合作战提供重要支撑。其核心是包括互操作标准在内的作战指挥标准化,因此要求发展一种语义参考模型,提供多国指挥控制信息系统(Command & Control Information System,C2IS)与建模仿真系统之间互操作的参考标准框架,该框架应能够促进多国指控系统领域用户、开发者和技术人员之间的交流。采用标准化的语义参考模型,进行异构军事信息系统[1-2]之间的互联互通和信息共享,实现语义乃至更高级别的互操作,不仅能缩短系统开发周期和部署时间,节约系统建设费用,更有利于提升系统的可扩展性和组件的可重用性[3]。
据此,北约多边互操作性计划(Multilateral Interoperability Programme, MIP[4⇓-6])发布了MIP信息模型(MIP Information Model, MIM),支持异构指挥控制信息系统的互操作,定义了支持国家指挥控制信息系统同步或交换的最小信息量的规范[7-8],并配套了信息模型替代开发与交换方法[9]及测试参考系统[10]等产品,以实现“从军团到营(或最低级别)的各级指挥控制信息系统的国际互操作性,支持跨国(包括北约)联合的作战行动。”
本文通过剖析MIM互操作标准的发展历程及典型应用案例,从强化联合多军兵种指挥控制与仿真域的合作,制定长远规划以及注重协调管理等方面,为促进我国在该领域的发展提供借鉴。
1 军事信息系统互操作
1)《美国国防部军事及相关词汇词典》:实体向其他实体提供服务和从其他实体接收服务并使用这些服务使得他们之间能够有效地协同工作的能力。
2)IEEE:两个或更多的系统或要素交换信息和使用已交换信息的能力。
3)仿真互操作标准化组织(Simulation Interoperability Standards Organization, SISO):在一个系统或过程中,通过其可交换的部件,在没有预先约定数据通信路径的情况下,实现系统各部件协调工作。
4)美军《系统之系统互操作性最终报告》:一套通信实体的能力包括交换指定的状态数据;依照指定的、一致同意的操作语义对状态数据进行操作。
5)我国《军用仿真术语》:一个模型或OSS向其他模型和OSS提供服务并从其他模型和OSS接收服务,以及利用这样交换的服务使各模型或OSS有效共同运转的能力。
军事信息系统的作战互操作性强调对军事行动的支持,而不依赖于系统(包括人员和程序等),在端到端的基础上互相作用。作战互操作性的实现意味着要同时具备传统的标准定义、任务驱动及信息保障,如测试、认证、结构、版本管理和训练等。作战互操作性与作战概念、作战场景、作战策略、作战方法和作战进程等密切相关,如果进行定量分析,应该是以这些方面为坐标的多维函数。所有的服务之间都存在交叉,所以,作战互操作性的内涵理解和定量描述非常复杂,需要根据具体的作战需求全方位综合分析[15]。
2 MIM开发历史
MIM的开发历史可以追溯到二十世纪八十年代美国陆军战术指挥控制信息系统(Army Tactical Command and Control Information System, ATCCIS)的通用网络中心(Generic Hub)。MIP是一个军事标准化机构,2001年,MIP与陆军战术指挥与控制系统(ATCCIS)合并,基于陆军指挥控制信息交换数据模型(Land C2 Information Exchange Data Model, LC2IEDM)扩展建立了指挥控制信息交换数据模型(C2 Information Exchange Data Model, C2IEDM)。2003年11月,该机构发布了C2IEDM数据模型6.1版本。2004年,北约数据管理小组(NDAG)与MIP合作研制联合协商、指挥控制信息交换数据模型(Joint Consultation, Command and Control Information Exchange Data Model, JC3IEDM)。JC3IEDM合成了北约协作参考模型,并纳入北约标准化协议5525,是目前美军国防部、盟国部队和商业机构正在使用的信息交换模式和主要工具,2004年12月发布JC3IEDM Ed 0.5。2009年9月发布MIP Baseline 3.0;2012年3月发布MIP Baseline 3.1[7]。最终,在JC3IEDM开发和使用中配套了MIM。
3 MIM组成结构
3.1 MIM功能设计
MIM的核心在于对来自不同领域的数千个军事相关概念的分类。它包括基本的战场空间概念——对象和行动,以及诸如计划、覆盖和组织结构等筹划概念。MIM具有一组丰富的属性来描述概念的固有特征、状态和能力以及它们之间的关系。元数据允许进一步丰富语义(例如:发起者、机密性和交换信息的评估)。MIM有一套工具和服务作为补充,支持模型的长期维护并允许生成交换模式。
MIM描述了军事相关概念及其在联合作战中指挥控制的关系。MIM在UML中被指定为类模型。MIM 5.1由768个类、162个复杂数据类型和478个枚举组成。类和数据类型有1 202个属性,其中,类通过172个不同的关联相互链接(不包括泛化)。6 901个枚举被定义,其中大约一半的值(3 121)表示鉴别码值的子类型。每个模型元素(类、关联、字面量等)都带有一个明确定义元素的定义。通过UML stereotypes,模型元素被进一步丰富语义信息,这些信息阐明了它们的预期用途和处理。除了类模型之外,MIM还包括自由文本文档、描述模型的选定子视图的类图以及UML对象模型方面的示例。目前,已经开发了几种工具来确保所有这些单独的模型组件随着模型的发展而保持一致。
3.2 MIM基本结构
MIM描述的实体关系如图2 所示。每个实体都来自一个通用的超类——概念(Concept),它涵盖了超过3 500种不同类型的分类。MIM 5.0版本引入的一个主要变化是BattlespaceConcepts和StaffConcepts。
作战空间概念(BattlespaceConcept)包含一个动作(Action)或者一个对象(Object)。Action可以是任务(Task)或事件(Event)。BattlespaceConcept指定执行Action所需、请求、分配或以其他方式使用的资源,以及动作的目标及其对对象(Object)或对象类型的有效性。一个Object允许表示许多不同的事物:一个参与者(Actor)包括Organization或Person)、设施(Facility)、网络服务(NetworkService)、材料(Materiel)、信息资源(InformationResource)或特征(Feature)。BattlespaceConcepts允许有一个位置,它们通常在地图上表示为战术符号。为了在地图上显示战术符号,需要将MIM的结构化信息转换为符号表示。APP-6(D)[23]之类的标准描述了MIM符号是如何构造的。为了便于根据APP-6(D)进行渲染信息的交换,MIM的位置(Location)模型不仅支持点、线、面和体积等标准几何类型,还支持MultiPoint作为特殊的图形类型。MultiPoint由预定义数量的定位点组成,以表达特定的形状。
人员概念(StaffConcept)是为支持特定作战流程而定义的结构。MIM定义了几种不同类型的StaffConcept,特别是计划(Plan)、命令(Order)、透明图(Overlay)和组织结构(OrganizationStructure)。通常,StaffConcept包括多个BattlespaceConcepts。例如,一个Overlay可能包含零或多个Object和Action,而一个OrganizationStructure由一个根Organization和从属Organization组成。每个StaffConcept可能有自己特定的交换语义。Overlay可以在作战期间通过添加、修改和删除其内容(即BattlespaceConcepts和嵌入的Overlay)来更新。相比之下,OrganizationStructure或Order一旦发布就不可更改,它作为在给定时间捕获快照的消息进行交换。
MIM从4.0版本开始,为对象层次结构的特定子树定义了单独的包(package)[19]。这些包根据类层次结构进行嵌套。例如,作为Object的直接子类的Material类被放置在一个名为Classifiers::Object::Material的包中。所有子类都放置在其超类的包中或其子包中。此外,数据类型(包括枚举)在使用它们的包中定义。如果一个数据类型被多个包中的类/数据类型使用,则该数据类型被放置在包含这些包的“最深”包中。多个顶级包中使用的数据类型被放置在一个名为Generic的包中。相同的规则适用于链接来自两个不同包的类的关联类。包数量的增加,结合类、数据类型和枚举的逻辑分组,提高了模型的模块化。
3.3 与其他互操作性标准的一致性
MIM的几个方面已根据其他引用源的最新版本进行了更新。单位分类(Unit Taxonomy)已与最新版的北约战术符号标准APP-6(D)保持一致。这简化了MIM中语义概念到APP-6(D)图形描述的映射。ADatP-3早期基线采用的几个代码列表已与最新的APP-11(D)保持一致。许多设施和特征(主要是geographic特征)的定义与北约地理空间信息框架(NATO Geospatial Information Framework, NGIF)和DGIWG特征数据字典(DGIWG Feature Data Dictionary, DFDD)中使用的等效概念定义保持一致。指挥控制信息系统通常将地理空间数据与C2数据相结合,因此MIM和NGIF或DFDD等互操作标准的一致有助于减少潜在的语义冲突[25⇓-27]。
但将MIM的结构化信息转换为符号表示时,APP-6(D)缺少两个关键元素:1)符号的几何形状通常没有在符号标准中以机器可处理的方式描述;2)信息建模的差异。符号标准自然地以视觉方式构建信息,因为它们需要确保在符号中捕获足够的信息。相比之下,MIM在语义上是结构化的,具有更深层次的BattlespaceConcepts和许多属性,其中大多数元素和属性不影响符号表示。因此,需要建立符号(由符号代码标识)与MIM的类和属性之间的映射关系。
此外,APP-6要求特定符号的特定几何形状,因此需要捕获此信息。MIM 5.1引入的MultiPoint在语义上捕获不同类型的几何定义(例如:由两个点定义的尾箭头、由3个点定义的S形箭头、由4个点定义的两条平行线等)。此外,MIM元模型为所有Battlespace-Concepts引入了一个标记值,称为geometry,它捕获了允许的几何定义。
3.4 MIM元模型
MIM是由UML指定的,UML提供了类、属性、泛化或关联等基本概念来指定类模型[28-29]。它还支持构造型(stereotypes)的概念,以便为UML模型中的单个元素添加更多语义。一个stereotypes可能有一组属性。如果将一个构造型分配给模型元素,则其属性将成为相应模型元素的标记值(tagged values)。标记值由建模者在设计时作为元数据提供。MIM广泛使用stereotypes丰富模型的语义注释。stereotypes提高了对操作概念的理解并推动了交换模式的产生。在某种程度上,stereotypes也可以被用来控制应用程序的业务逻辑和用户界面。MIM指定了两个互补的UML配置文件,每个配置文件定义一组原型,它们形成了MIM元模型。
举例说明如下,图3 显示了包含“cls” stereotype的Bridge类。该类包含dimension、code、quantity等属性。描述性术语(Representation Terms)为属性提供特定的元数据,例如,度量单位、最小值和最大值或给定标识符的方案。Bridge类“继承”了许多标记值,例如externalSource、geometry、name和semanticID。Bridge类的属性有一个stereotype,有些类甚至包含多个。
接下来概述如何使用stereotype丰富MIM的语义信息。
1)描述性术语
属性的数据类型(例如:Integer)定义了它的有效值,但它很少说明属性的预期用途。出于这个原因,一个描述性术语(根据UML stereotype)被分配至MIM中的每个属性。描述性术语集包括日期、比率、维度、数量等。根据具体的描述性术语,建模者必须指定额外的元数据,例如:最小值、最大值或测量速率、数量等的单位。描述性术语集遵循UN/CEFACT核心组件数据类型目录[30],并带有一些扩展(例如:速度)以避免潜在的歧义。
2)类型vs实例vs状态属性
MIM概念的属性根据它们是否被指定为类型、实例或状态信息进行分类。例如,Bridge的设计类型被认为是“type”属性,而给定的Bridge会有一个真实的跨度。其他属性可以表征一个对象的状态,例如:一个单元的准备情况。
3)角色(Roles)
MIM区分自然对象和对象所扮演的角色。例如,Reporter是Person或Organization扮演的角色。MIM中定义的其他角色是Recipient、Observer、Originator、PointOfContact和SecurityPolicyAuthority。角色可以采用其自然对象的属性(例如:姓名或地址),也可能有独特的角色属性。
4)托管代码(Managed Codes)
MIM中的大多数枚举(代码)都有一组预定义的文字(值)。但是,在某些情况下,维护MIM中所有有效值的列表是不可能或不切实际的。例如,国家/地区列表很长,并且定期更改、维护它会给数据建模者带来一些负担。此外,只有一小部分与特定任务的背景相关。另一个例子是信息的安全分类。MIM中指定的值是北约内部使用的值。但是,国家可以在具有特定国家分类的北约领导的行动中共享信息。其值未在MIM中固定的代码被声明为“托管”。在指挥控制信息系统的支持下,它们需要特殊处理,并且它们的值需要在执行任务之前被定义。
5)完整代码vs不完整代码
有些代码可以认为是完整的。例如,枚举DayNight包含Day、Night和DayAndNight。这组值是完整的,终端指挥控制信息系统用户不应该“发明”另一个值。在其他情况下,代码可能包含最可能/最常用但未被视为完整的值。MIM中的所有代码都被系统地标记为它们是否完整。
6)顺序代码
一些代码定义了它们的值之间的顺序。例如,枚举PrimacyCode包含Tertiary、Secondary、Primary,并定义了它们之间的排序关系(“优先级递增”)。同样,TroopReadinessCode的值遵循严格的顺序(从“365天内准备好”到“2天内准备好”)。MIM元模型允许将枚举指定为有序并定义对应关系。在搜索/过滤信息时,指挥控制信息系统可以利用此信息。
7)语义ID(Semantic IDs)
每个模型元素(类、数据类型、枚举、属性、文字、关联)都有一个唯一的语义ID。根据 IETF RFC 4122[30],语义ID被定义为通用唯一标识符(Universally Unique Identifiers, UUID),其值没有意义。即使元素在语法上从模型的一个版本转换为另一个版本,模型元素的语义ID也会被保留。例如,一个类可能被重命名(同时保留其原始语义)或移动到另一个包。在某些情况下,文字可能会转换为类或数据类型。语义ID对跟踪不同模型版本之间的概念非常有帮助,它们支持向后兼容。随着MIM的发展,它们还使维护与其他标准(例如APP-6)的映射变得更容易。
8)关系分类
MIM中的所有关联都根据它们是否表示空间、结构、功能、社会或时间关系进行分类。
9)缺乏信息
MIM约定:当信息缺失时,即使是强制信息也不允许交换。在北约多国行动期间,不同国家信息系统之间无法交换特定信息的原因如下[19]:
①提供的代码值列表不包含适当的条目(在这种情况下,用户可能希望提供他/她自己的值)。
②没有有用的价值。这些信息在给定的上下文中没有意义。
③正确的值不容易获得,甚至将来可能无法获得。
④该值稍后可用。
⑤发送者不知道正确的值,也无法计算正确的值,但是,可能存在正确的值。
⑥不泄露价值。安全限制禁止其交换。
MIM定义了NilReason类以允许指定不提供信息的原因。想要基于MIM构建互操作性解决方案的设计师在定义特定平台的模式时必须考虑这个概念。该概念主要受地理标记语言(Geography Markup Language, GML)中的NilReasonType启发,但并不完全相同。MIM的设计是基于任何属性可空的假设,即可以为任何模型元素指定NilReason,因此,用户可以表示缺失信息。于是,不再需要向单个枚举添加特殊文字,例如其他、未知或未另行指定,因为它们超出了MIM的范围。“可空性(Nillability)”的概念不限于类型枚举的属性;它同样适用于其他类型的属性,例如布尔属性。如果MIM定义了一个强制的Boolean属性(例如isActiveIndicator),其值为TRUE和FALSE,则假定终端用户仍然能够表达无法传递的状态并能够提供原因。
4 MIM的生态环境:工具和服务
1)链接数据服务器。链接数据服务器允许加载多个版本的MIM,并提供一个ReST API和Web界面查询不同的模型版本[34]。它支持模糊搜索并遵循链接数据的原则,其中每个资源都可以通过唯一的资源定位器(Unique Resource Locator, URL)访问。主题专家和数据建模者可以使用Linked Data Server在MIM中快速查找术语并浏览模型,而无须掌握复杂的建模工具。
2)修改提议(Change Proposal, CP)工作台。CP是修改模型的工具。在对提议的变更进行正式投票的跨国组织中,拥有明确的、机器可处理的变更提议非常重要。在应用修改提议时,它会自动执行许多人工处理和验证步骤。CP允许用户创建一个更改提案,详细说明所有设想的更改。该工具确保提供所有相关信息(包括刻板印象和相关元数据)。它还确保用户处理语义ID。通过在试运行中将修改提议应用于模型,该工具会检查更改是否适用,并保留模型的命名和设计规则。然后,各国可以对修改提议进行投票和发表评论。一旦修改提议被接受,修改提议工作台允许以自动方式将修改提议应用于模型。CP也支持用户自定义扩展MIM。MIM随着时间的推移而发展,领域社区希望将其扩展重新应用到模型的未来版本中。
1)XSD/OWL生成器。由于MIM的建模独立于平台,因此,需要额外的处理器导出平台特定的模型和交换模式。XML Schema生成器和OWL生成器就是这样的处理器,它们分别创建XML Schema和OWL表示。在XML Schema中,MIM的语义注释被保存为xsd:appinfo,可以在运行时使用。
2)消息生成器(Message Builder)。消息生成器是用于创建模型的专用子集的工具。
3)模型差异(Model Diff)工具。模型差异工具使用语义ID显示两个模型版本在句法和语义级别上有意义的差异。比如5.1版本和5.0版本的对比中,MIM 5.0会显示:UnitGeneralMobilityCode.WheeledLand代码值被删除,或LandMobilityCategoryCode.Wheeled代码值被引入,事实上,两者在语义上是等价的。该信息作为指导特别有用,希望在指挥控制信息系统中支持多个MIM版本的实施者。
4)维护脚本。Sparx EA模型中,MIM包含一组自定义脚本,有助于确保类模型、图表、示例和文档的一致性。
5 MIM信息交换过程
北约各盟国之前定义了诸多面向本国C2域内信息交换的互操作性标准[19]。这些标准可以满足特定要求,例如战术层面的通信、情报或C2模拟信息交换。然而,这些标准使用的概念存在重叠。MIM被认为是一个语义参考模型,它定义了许多兼容不同互操作标准可用于共享的概念。当n个不同标准需要实现n-1个接口与所有其他标准交换信息时,它需要解决n个问题。
MIM定义了作战概念(根据UML类)及其关系。它没有定义平台特定的细节,例如序列化的格式。此外,它是独立于信息交换的上下文建模的。MIM是一种具有类图结构的模型。UML类以各种方式相互关联,从而产生潜在的直接和间接循环依赖关系。在交换模式中,这种循环结构是不需要的。相反,树结构更适合交换消息。
5.1 扩展和限制MIM
MIM统一了许多不同来源和用于不同目的的信息交换要求。因此,没有任何一个指挥控制信息系统会完全采用MIM。此外,可能存在MIM中未反映的互操作标准要求(因为它们可能与跨互操作标准的信息交换无关)。在定义信息交换规范时,它们必须到位。
任何MIM的应用程序都可以根据自己的需要定制MIM,并构建自己特定的系统模型(通过尽可能多地重用MIM)。但是,这种定制不应以任意方式进行。为支持跨指挥控制信息系统的信息交换,应适用以下规则:“如果MIM的应用程序采用MIM中的概念C,并根据自己的目的对其进行调整,从而产生C',那么C'的任何实例应该是C的有效实例。”
在UML方面,MIM应用程序可能会做出以下限制:
1)限制属性的多样性(属性和关联端)。MIM应用程序子模型中的多重性必须是MIM中多重性的子范围。形式上,假设MIM中的属性具有多重性[x, y],其中x是下限,即最小出现次数,y是上限。那么MIM应用程序子模型中的多重性必须是[x', y'],其中x≤x'且y≥y'。因此,可选属性[0,1]可以变成强制属性[1,1],完全忽略[0]。但是,强制属性[1,1]不得由MIM的应用程序声明为可选。关联端同理,即如果类C1与类C2有关联,则与C2相关的关联端的多重性为[0, *],从C1的角度可以完全忽略该关联。
2)限制代码值的集合。MIM中的枚举可能会定义为特定用例中没有意义的文字,但允许MIM的应用程序限制文字集。例如,VehicleCategoryCode定义了许多不同类型的车辆,但并非所有车辆都能在特定上下文中需要。
3)定义默认值和固定值。互操作标准属性支持定义为默认值和固定值。例如,属性isDecoyIndicator指定对象是否被明确设计为诱饵,在MIM中是强制性的。在某些领域,可以假设大多数对象不是诱饵。在这种情况下,该属性应设置为默认值false。同时,属性存在应该分配固定值的情况(在UML中,如果属性具有默认值并声明为只读,则属性具有固定值)。例如,在计划战斗命令(ORBAT)时,可以假设所有参与的单位都将其敌对状态代码设置为友好。
4)定义特定领域的约束。使用诸如对象约束语言(Object Constraint Language, OCL)之类的通用形式语言,MIM的应用程序可施加无法在UML中表达的进一步约束。例如,对于不同属性的有效值的组合,可能存在特定域的限制。只要不与底层模型冲突(并且隐含地与上述规则冲突),约束的类型一般不受限制。重要的是,说明上述规则不会自动强制不同MIM应用程序在两个方向上的互操作性。任何MIM应用程序都可以基于MIM与其他MIM应用程序共享其信息。然而,为了支持内部流程,可能必须遵守额外的限制条件,并且需要考虑信息交换的背景。由各个MIM应用程序决定如何集成(丰富/修改)来自外部的MIM兼容信息。
5.2 定义消息模型
在构建MIM消息模型时,需要考虑几个方面:
1)MIM的可追溯性:从不同互操作标准消息模型中的模型元素到MIM中相应概念应该有引用。理想情况下,MIM元素的重用方式应该是标准工具立即将其识别为MIM概念(通过使用相同的URI)。一个较弱的解决方案是引入从不同MIM应用程序消息模型的元素到MIM对应项的链接(通过使用语义ID)。该链接可以在消息定义中指定(例如,作为包含MIM语义ID的XML Schema中的appinfo元素)或通过外部映射文档指定。
2)可读性:不同互操作标准消息模型的设计方式对主题专家和实施者应易于理解。
3)维护:不同MIM的应用程序消息模型应易于维护,以响应不断变化的需求。此外,随着MIM的发展,可以对不同MIM的应用程序模型进行影响分析。
4)组件的重用:在许多不同类型的消息中都有组件(也称为段)。一个典型的例子是Unit和其Location组合。应该可以在多个MIM的应用程序之间共享这些常用组件。
5)协调支持:如果几个不同MIM的应用程序将相似或相同的概念引入其特定模型,则这些概念是MIM内统一的候选者。MIM特定应用程序的扩展应该以一种易于反馈给MIM的方式来指定。
6)指导定制流程:定义MIM特定应用程序的子模型应由工具支持,以确保应用被有效限制。
7)在不同的上下文中使用概念:经验表明,相同的操作概念可以在同一消息的不同上下文中使用。根据上下文,不同类型的信息可能是相关的,因此,必须对同一概念应用不同的限制。例如,消息模型中的不同位置可能需要不同的元数据(报告时间、安全分类等);或在MIM术语中,需要讨论对象所扮演的角色;ORBAT消息模型中的一个单元可能扮演计划组织或下属单元的角色;在一个理想的模型中,所有相关的角色都已定义好,实际上情况并非如此。
5.3 技术方法
MIM应用程序可以通过多种方式指定其逻辑消息模型。接下来将讨论一些替代方案的优缺点。
5.3.1 复制调整
构建于MIM特定应用程序模型最简单的方法包括以下几个步骤:
1)创建MIM副本;
2)手动删除所有不需要的元素(例如,通过使用UML建模工具);
3)使用为MIM提供的XSD生成器从修改后的模型创建新的XML Schema。
步骤1)和2)可以通过在复制模型时选择MIM的一部分来组合。MIM支持这种方法以及步骤3)。所需元素以及新元素以XML格式指定,并由称为CPProcessor的工具创建/操作。上述过程的最终结果是一个新的交换模式,它遵循与MIM相同的命名和设计规则,并将模型元素保留在其原始MIM命名空间中,即它们与原始MIM元素没有区别。
这种方法非常灵活。但是,它不允许在不同的上下文中使用具有不同限制的MIM概念,即每个MIM概念仅适用于一种特定的限制方式。此外,定义MIM应用程序子模型的建模者仍然必须处理导致非树结构的关联。
5.3.2 基于UML类图的建模
MIM应用程序特定的子模型可以由UML图指定。形式上,UML图描述了更大模型的子视图,而不是子模型。
Sparx EA允许指定应在UML图中显示的内容,直至单个属性和文字的级别。这意味着可选属性和关联可能会隐藏在特定视图中,并且可能不会列出文字。在Sparx EA中,可以嵌套UML类图以指示分层消息结构。图6 显示了一个PersonLocationReport,它由两个部分组成:ReportHeader和PersonLocation。每个段都表示为另一个包含MIM元素的类图。
在派生交换模式时,嵌套元素的顺序必须已知。它们各自图框的相对位置可以帮助确定顺序(从上到下,从左到右)。另一种选择是利用UML建模工具的灵活性并指定图表之间的“组合”关系。例如,在图6 的示例中,PersonLocationReport可以是具有组合关系的图表(甚至是类)。通过用序列号标记组合关系,可以明确地定义交换模式中指定元素的顺序。
属性的多样性无法在特定图表的范围内修改,这种修改必须在基础模型中完成。同样,嵌套图的多样性也没有正式的方法来表达。因此,单独的类图不足以完全指定MIM应用程序消息模型。克服此限制的一种方法是在类图旁边以正式的方式指定所有必需的限制。通过自动化工具,可以生成一个新的子模型,包括类图中列出的所有元素和所有限制。使用UML类图的优点是保留了与MIM的强耦合。如果MIM发生变化,类图也会发生变化,这要归功于UML建模工具。但是,更改将在建模者没有注意的情况下持续传播。将图表和限制转换为特定于MIM应用程序的子模型的过程是可重复的,并且如果基础MIM以与限制不兼容的方式发生变化,则可能会出现冲突。
5.3.3 消息生成器
消息生成器(Message Builder)用于生成即时模型。基于这个想法,以交互方式构建树状消息格式,如图7 所示。消息生成器是一种利用MIM进行特定信息交换的工具。它允许创建针对特定用例的MIM子集。例如,一个MIM应用系统可能想要定义一条只使用一小部分MIM消息用于友军跟踪的用例。其工作方式是用户以交互方式为它创建消息的起始类。它成为消息的根元素。随后,该工具允许用户添加可从根类直接或间接访问的属性、关联和子类。在此过程中,当用户包含一个类或复杂数据类型时,该工具会自动插入所有人工数据属性和关联,保留基础模型的语义。
用户可以通过强制可选属性或将一对多关联转换为一对一关联来限制选定的属性和关联。这意味着,对于特定的用例(这是消息的用途),可以显式地对附加约束进行建模。例如,在创建蓝军跟踪消息时,用户可能决定强制指定军事单位的位置。一旦用户建立了消息定义,它就可以快速生成消息的UML表示。此外,用户可以直接从消息生成器中创建一组XML Schema。这些模式在实例级别与为整个模型生成的XML Schema兼容。这意味着实现消息超集的系统无须进一步调整即可自动支持消息实例的接收。
消息生成器支持定义支持顺序报告的特定人员概念。假设所有相关概念在MIM中都可用,或已由MIM应用系统作为扩展添加,消息构建器允许构建多个消息,这些消息都依赖于相同的语义参考模型。如果C2流程由具有强烈语义重叠的几种类型的交换消息支持(当前的APP-11消息目录无法确保这一点),将具有特殊意义。它还确保消息建立在相同的战场空间概念之上,这些概念通过叠加层交换,成为不断更新的识别图片的一部分,如图8 所示。
消息生成器已成功应用MIP4.3-IES生成消息模式。XML Schema是为Friendly ORBAT/Task Organization和Non-Friendly ORBAT生成的。北约数据管理能力小组对APP-11消息友军信息(Friendly Force Information, FFI)进行了分析,并生成了MIM等效模式。经验表明,从MIM中指定单个消息是可行的。然而,现有的消息格式(例如,从APP-11转换为基于MIM的消息)并不简单,会引发语义问题,因此,需要主题专家的参与。另一个观察结果是生成的模式可能不如预期的小。例如,对于任务组织,必须能够指定各种单位(Units)和设备(Equipment)。因此,必须包括各自分类法的大部分内容。消息生成器通过允许将整个类型层次结构折叠成一个代码值的平面列表来解决这个问题(同时保留前子类的所有属性)。
5.3.4 扩展MIM概念
以前的方法修改了MIM的模型元素(类、属性等),并将修改后的版本放置在MIM命名空间或特定的MIM应用程序命名空间中。另一种选择是保持原始MIM概念不变,并从中派生实现限制的子类。UML支持这种方法,但并不常用。OWL和XML Schema语言也支持扩展和限制。例如,可以将 MIM概念导入OWL本体(例如:coiA:MyUnit扩展/限制MIM:Unit)。同样,XML Schema支持两种分类型:通过扩展和通过限制。
6 结束语
MIM的下一个版本计划于2022年秋季推出。它将采用新的方式来指定和链接信息和通信技术(Information and Communication Technology, ICT)服务,将满足更多的空中需求,并且具有更好的性能[35⇓⇓⇓-39]。当前,MIM侧重于陆军、海上和空中领域,未来将支持赛博空间。为此,MIP与北约联合符号小组(Joint Symbology Panel)密切合作,以使计划为APP-6(E)的网络扩展与即将推出的MIM概念保持一致。另外,MIM附带一套软件工具,支持模型的维护、交换模式的自动生成以及特定兴趣社区对模型的定制[40-41]。在GNU通用公共许可证下,所有工具都以二进制和源代码的形式免费提供。