数据链系统互操作性管理与保障技术
2021-04-13徐山峰周翔王兆伟
徐山峰 周翔 王兆伟
1.中国电子科学研究院北京100041
数据链系统是在一定的战略指导和作战使命任务需求下,为完成各种作战任务,连接各类独立的武器平台进行集成,使其相互协同,形成单装备不具备的体系作战能力的系统.数据链系统不仅包括单装备数据链系统设备、联合指挥系统以及指挥应用显示,而且包括各个平台系统之间作战指令、数据等作战情报的互操作[1−2].
数据链为战场平台、人员和设备提供近实时的信息交互,以应对开放复杂环境下的各种作战挑战,各个信息交互单元可以看成联合作战系统中自治的个体,互操作性可以保障信息在各单元以快速、高效和有序的方式交换,支持作战行动的快速开展和作战目标的迅速完成.数据链互操作性保障的主要方式是消息标准的互操作性,通常认为,当战场中的信息交互单元都采用同一消息标准时,就应该不存在互操作性问题.但是,在实际的工程实践中,由于消息标准缺乏完备性和一致性,互操作问题是难以避免的,主要表现在[3−4]:
1)消息标准是不断演进的.
2)不同用户对平台的作战需求不一致,进而导致消息标准存在不一致的地方.
3)同一平台在不同时期研发和建设,可能采用了不同版本的消息标准.
4)不同的人员对消息标准理解不一致.
因此,研究基于消息标准的数据链系统互操作性保障技术,建立对数据链系统的需求分析、演化和管理的能力,为各个作战平台的数据链集成提供互操作性分析、保障和验证手段,对数据链系统整个生命周期提供技术与管理支持,从而满足数据链系统的作战使命和任务.
1 数据链系统的互操作性
为保证各种数据链设备或系统共同使用时能够高效地进行信息交互,对数据链系统的互操作性定义如下:数据链系统的互操作性是指两个或两个以上的数据链系统或设备相互协作,实现特定的功能或提供特定服务的能力.互操作性是建立在信息共享的基础上,信息互换是互操作的基础,互操作是信息应用结果的体现[5−7].
以数据链消息为核心,按照自内向外、逐层支撑的方式设计数据链系统互操作模型,从上到下分为作战级、系统级、设备级以及数据级.各级互操作性从作战级逐级分解,形成可互操作的数据级消息;通过数据链完成数据级互操作后,从数据级逐级完成数据解析并在作战级进行输出.如图1所示,首先将作战级的作战场景和作战意图输入到操作员,操作员根据当前信息作出相应的决策并进行人机交互,进而在平台形成需要交换的数据,然后将数据按照消息标准分解为可互操作的消息,并通过数据链传输到系统接收设备,在系统数据接收设备端将数据按照消息标准拆解为计算机可识别的消息,并在人机交互界面输出,操作员根据收到的信息指挥作战输出.
图1 数据链体系互操作性模型Fig.1 The interoperability model of data link
2 互操作系统管理与需求转换过程
2.1 简介
联合作战需要在传感器、射手和指挥控制单元间实现精确、快速、安全的网络互联和信息共享,互操作性是作战有效的关键,需要在数字信息系统的全生命周期中被考虑、设计、保障和评估.互操作系统管理与需求转换(interoperable Systems Management and Requirements Transformation,iSMART)是一个由数据库和工具包支持的严格、有序的过程,采用系统工程的方法,通过系统间的信息流分析,管理系统或装备全生命周期中的信息交互需求,以较低的成本协助项目开发者在空基、陆基、地面或水下等作战平台上,正确集成一个或多个数据链装备,为用户提供平台数据链的实现信息和细节,使平台在使用中发挥最大优势,加速美军升级转型,提高联合作战能力.其主要作用有:
1)在能力定义过程中,对平台性能的感知更为详细.
2)减少歧义,增强用户、管理方、系统设计人员、软件开发人员之间的互相理解.
3)明确数据链系统的认证和测试,使其更高效.
2.2 主要过程
iSMART 是将高层级互操作性需求转换为具体数据交换需求的方法,如图2所示,其主要步骤如下[8−9]:
1)从操作层面和能力层面出发,定义项目必须的数据交换需求,以满足用户的操作需要.例如,如果某个平台的作战目标是快速、高效地打击高价值时敏目标,则其在作战过程中需要通过数据链系统传输图像进行必要的信息交互.
2)项目管理或开发机构根据数据交换需求,从已有的数据链装备中选择最佳的解决方案,如果现有的装备存在能力差距,则需要改进已有数据链装备或研发新型数据链系统.
3)为项目开发联合能力集成与开发系统(Joint Capability Integration and Development System,JCIDS)文档,保障数据链系统全生命周期的联合作战能力,为项目开发iSMART 文档,保障数据链系统全生命周期的互操作性.
4)项目管理或开发机构建立集成过程工作组(Integrated Process Team,IPT)为每个已选定的数据链系统开发消息交换需求.IPT 主要由项目管理人员和项目开发人员,以及空军、海军、陆军、海军陆战队等最终用户的互操作性专家组成.
IPT 的主要工作有:
1)制定高层级消息实现需求,确定本平台的数据链消息、消息字和具体数据取值范围.
2)根据高层级消息实现需求,确定本平台数据链系统的信息交换需求、数据传输协议和互操作矩阵,确定本平台需要通过数据链系统交互信息的对象、业务和互操作等级.
3)开发平台需求规范(Platform Requirements Specification PRS),确定本平台数据链协议的比特级需求,PRS 和消息标准不一致的情况,分类记录在平台需求差异文档(Platform Requirements Difference Document,PRDD)中.
4)开发实际平台执行规范(Actual Program Implementation Specification APIS),按照PRS 实现数据链协议,给软件开发人员分配平台主机软件开发项目,实现数据链系统的主要功能,解决遇到的工程问题,并在APIS 中详细记录相关实现细节,主机软件测试后,在APIS 中记录部署或实际实现的数据;平台具体实现与消息标准不一致的地方记录在平台执行差异文档(Platform Implementation Difference Document,PIDD)中.
6)通过互操作性测试认证,获得联合互操作性认证.
7)在平台的全寿命周期过程中持续获得关于数据链系统互操作性的反馈,当数据链系统的互操作性不能满足平台的作战需求时,进行迭代开发.
平台集成的数据链系统的类型、数量和具体某一特定数据链系统的互操作性需求,通常取决于以下因素:
1)平台任务,平台任务域决定需要哪些消息和协议在平台上实现.
2)平台人员配备,大多数数据链功能是自动的,但是一些活动必须由操作员执行,如果平台需要实现某个能力,而没有人员能够完成交互工作,平台将以其他形式实现该能力,或取消该能力.
3)平台硬件能力,平台可能受限于其传感器、无线电或其他设备的能力,这些限制要记录在PRS 或PRDD 中.
4)进度,如果平台使用增量开发过程,IPT 应该确认每个增量实现的功能持续与其他网络平台的互操作.
图2 iSMART 主要过程的示意图Fig.2 The process of iSMART
2.3 文档开发
消息标准定义了作战所需要的完整集合,哪些元素和文档是数据链系统和平台必须的,仍需要决策.iSMART 能够有效解决复杂的互操作性问题,通过定义一整套文档实现需求转化和互操作管理.iSMART 通常根据北约战术数据链出版物或美军消息标准,确定使用的战术数据链类型和信息交换需求.同时,需要确定消息标准的文档版本,作为iSMART 文档演进的基线.
如图3所示,消息标准版本选定后,根据分层模型,iSMART 文档管理向国家需求文档层面演进,消息标准实施的部分称为国家需求规范(National Requirements Specification NRS),消息标准不采用的部分称为国家差异文档(National Difference Document,NDD).对于NRS,定义了该国家层面采用的消息标准内容,主要包括平台的功能,消息内容和消息字,以及消息字的数据元素;NDD 定义了不采用消息标准内容的平台功能,以及不采用的基本原理.
第2 层级的文档主要考虑服务层面的文档管理,提供美国陆、海、空等军兵种对每种服务的需求信息.服务层级的文档格式与国家层级相似,包括服务需求规范(Service Requirements Specification SRS)和服务差异文档(Service Difference Document,SDD).绝大多数国家的武装力量没有强大到需要区分不同服务,通常认为只有美军使用服务层级文档.
第3 层级的文档主要考虑平台层面的文档管理,包括PRS 和PRDD.PRS 主要描述平台发送和接收数据链消息的比特级信息需求,为平台提供精确的协议实现需求;PRDD 详细描述平台对数据链系统的集成需求,以及和消息标准之间的差异(消息集、消息格式、消息标识、数据项等).对于指挥控制平台,平台的需求主要包括:1)基本功能,主要包括消息交换、信息接口、网络参与等.2)平台感知.3)网络管理.4)空间、空中、水面、地面警戒.5)导弹防御.6)电子战.7)武器控制.8)空域控制.9)指挥控制.
图3 iSMART 文档构成示意图Fig.3 The structure of iSMART document
第4 层级的文档为平台执行文档,描述平台数据链能力的达成情况,主要包括APIS 和PIDD.APIS描述了具体平台中消息标准的实际实现情况,主要记录了具体平台中数据链消息的比特级定义、传输协议、实际实现和测试阶段解决的功能性问题(以RPS 为基线),可以认为是平台数据链最终技术状态的描述,通常作为平台测试的基线;PIDD 详细描述了具体平台集成数据链的功能性能要求、消息集、消息实现与消息标准的差异,以及和消息标准之间的差异原文、差异原理、相关影响等.PRDD 和APIS中的差异部分应包含以下信息:1)差异部分在消息标准中的位置.2)差异的说明(增加、删除或修改).3)差异的原文.4)差异的基础原理.5)差异对互操作性的影响.6)差异对消息处理规程的影响.差异的原因应尽量标准化,以促进跨平台类型和跨平台间的对比,保障系统间的互操作性.
2.4 互操作性测试认证
互操作认证主要验证两个或两个以上的数据链设备/系统相互协作,各自实现特定的功能或为各自所面向的用户提供特定服务的能力.从过程出发,互操作认证又分为静态互操作认证和动态互操作认证.静态互操作认证,指不进行实际互连测试,对待测试数据链设备提供的消息交换需求文档、PRS、APIS等文档进行对比分析来发现互操作性问题.动态互操作性认证则是搭建测试环境,将被测设备直接同其他设备相连进行实际的测试[10−11].
互操作性测试认证过程是一个连续过程,其主要过程如下:
1)互操作认证申请
若某设备或平台需要进行互操作认证,其负责单位应向互操作认证单位提交认证申请,并提供相关互操作文档、消息标准的比特级别实现基线、产品能力基线和关键性能参数文档;互操作认证单位根据提交的文档,进行静态互操作分析和验证,并决策是否接受该互操作验证申请.
2)开发互操作测试和认证大纲
互操作认证单位根据互操作认证申请中的文档,为待测设备或平台开发互操作测试和认证大纲,详细阐述待测设备或平台的互操作对象、互操作测试计划、测试方法和测试数据.
3)执行互操作测试和认证
互操作认证单位搭建互操作测试环境,构建互操作测试场景,按照互操作测试和认证大纲执行动态互操作测试,并记录相关测试数据.测试过程中需重点关注待测设备或平台的消息标准一致性测试和联合互操作性测试.消息标准一致性测试是测试待测设备或平台的消息标准具体实现与消息标准在信息内容、格式、传输协议、处理规则等方面的符合程度,一致性测试是互操作测试的技术基础.联合互操作性测试是判定待测设备或平台执行联合作战任务时与其他已有设备或平台的互操作程度,如果有特殊需要,可以进行专项互操作测试,验证判定待测设备或平台与某个特定设备或平台的两两互操作.互操作测试必须评测端到端的信息交换和使用,并满足信息交换和使用的完整性、精确性、及时性、安全性和服务质量要求.
4)给出互操作认证结论
互操作认证单位分析测试数据,进行结果分析,给出互操作测试和认证报告,并作出互操作认证通过或不通过的结论.
5)互操作技术状态维护
互操作认证通过后,已认证设备或平台的管理部门应持续关注其互操作技术状态,并把出现的互操作问题或互操作技术状态变更情况报送互操作认证单位.如果已验证设备或平台的互操作问题过于突出,应启动新一轮的互操作认证过程.
3 生命周期中的互操作性保障
iSMART 产品开发顺序与JCIDS 产品开发过程类似,如图4所示,iSMART 文档基于JCIDS 文档相同的政策,支持严格的系统工程过程,将与整个JCIDS 过程互补[12−15].
JCIDS 进程所有者已经制定了支持架构要求的政策,允许组件和下级命令调用JCIDS 进程各级要求,JCIDS 主要由基于能力的评估(Capability-Based Assessment,CBA)、初始能力文档(Initial Capabilities Document,ICD)、能力开发文档CDD (Capabilities Development Document,CDD)、产品能力文档CPD(Capabilities Production Document,ICD)4 大功能来构成.
CBA 提供了发现需求和相关的能力缺口分析依据,在提交能力要求文件以供审查和确认之前,主办方使用CBA 识别军事能力需求和能力差距,以及潜在的非装备和装备方法,减少能力差距.ICD 指定一个或多个能力需求以及相关的带来不可接受的行动风险的能力缺口,ICD 是CBA 的结果,其目的是记录能力要求和相关的能力差距,在这种情况下,主办方认为未履行的能力差距的操作风险是不可接受的,ICD 还建议使用非装备的、装备的或者二者结合的能力解决方案部分或全部弥补能力缺口;验证的ICD 是每个装备开发决策必需的准入标准.CDD 指定能力需求,通过开发可用的表现属性,以及其他支持发展所需的相关信息来支持解决方案的一个或多个增量,主办方批准的CDD 草案支持采购阶段的里程碑A 的决策点.CPD 提出装备解决方案的专业增量产品,该解决方案旨在全部或部分满足验证功能需求和关闭或减少相关的能力差距,CPD 规定了能力需求和生产性能参数,以及相关支持生产单装备增量所需信息的方式呈现;验证的CPD 是里程碑C采购决策点的前置需求.
数据链系统全寿命周期互操作过程可分为消息需求开发阶段、PRS/PRDD 开发阶段和APIS/PIDD开发阶段.在里程碑A 阶段之前应该成立相应的数据链互操作开发团队,在技术开发过程中,为待开发的数据链系统和待集成平台开发消息交换需求,确定数据链系统互操作输入,降低技术风险,并在里程碑B 之前完成消息交换需求的审查.在制造开发的初始阶段,应该为数据链集成平台开发PRS/PRDD,确定平台对数据链的集成需求,并提交权威机构进行审查;审查后的PRS/PRDD 作为平台互操作性开发的基线,为后续互操作性开发、集成和验证提供参考.在工程和制造开发的后续阶段,完成数据链集成平台的APIS/PIDD 文档开发,为具体平台提供准确的、比特级别的消息标准实现记录,用于维护平台数据链的实际软件性能,以及后续数据链消息设计和管理过程的互操作性对比.
图4 数据链系统全寿命周期互操作过程Fig.4 The interoperability process of data link in life cycle
4 结论
通过对美军互操作系统管理与需求转换过程研究,有以下几点建议可供参考:
1)完善协同工作机制,改进数据链系统顶层设计与管理体制,建立数据链全生命周期互操作性保障机制,解决数据链系统互操作问题.
2)建立对数据链系统的需求分析、演化和管理的能力,研究数据链系统互操作性管理、保障、测试、评估、决策的体系和手段,确保数据链系统根据任务和使命来进行分析和设计.
3)以需求为牵引,对数据链系统相关的作战平台项目进行互操作性管理、监督和认证,实现各平台的交互、协同工作,确保联合互操作性.
4)从能力角度出发,对数据链系统整个寿命周期提供技术与管理支持,对其处于不同的寿命周期阶段进行整合,形成数据链系统全生命周期的技术管理.