美军协同交战技术发展研究综述

协同交战（Cooperative Engagement）一词最早可溯源至20世纪70年代后期。为克制美军航母战斗群，苏联于1958年开始，先后发展了多型反舰导弹，射程扩展至500 km以上，速度扩展到超音速，大幅压缩了宙斯盾的拦截窗口时间，使得美军航母战斗群的战场生存能力面临严峻挑战。为解决这一问题，1975年，美国海军资助约翰•霍普金斯大学应用物理实验室（APL）开展“战斗群防空作战协同”（Battle Group Anti-Air Warfare Coordination, BGAAWC）概念研究，主要实现舰队武器平台之间共享目标探测数据，扩展目标捕获和拦截范围。

协同交战技术的核心是将分布在战场不同位置的传感器和武器进行网络化集成，扩展和统一杀伤链全环节的战场覆盖空间，最大限度发挥防空武器的动力射程潜力，有效增加拦截窗口时间。美军先后发展了协同交战能力系统（Cooperative Engagement Capability, CEC）、战术组件网（Tactical Component Network, TCN）、单一综合空情图（Single Integrated Air Picture, SIAP）和海军综合防空火控系统（Naval Integrated Fire Control-Counter Air, NIFC-CA）等，其历程对空基信息系统建设有一定的启示，值得我们思考和借鉴。

1985年，BGAAWC计划进行了名为“基于搜索的远程跟踪目标发射”的试验，试验结果表明Link-11数据链的带宽和时效性不能满足协同交战要求，也就是基于当时的Link-11数据链进行升级改进无法满足舰队协同防空的要求[1]。为应对反舰导弹威胁和复杂的濒海作战环境，1987年美海军正式启动CEC计划，研制协同交战装备。由约翰•霍普金斯大学应用物理实验室进行技术指导，雷声公司作为主承包商。CEC原计划1996年完成初始作战能力鉴定，但是1997年以后开始的真实性作战试验和评估并不顺利，主要是战斗群互操作性和软件可靠性方面还存在重大的问题，1998年系统进入小批量生产阶段，全速生产则被推迟至2003年[2]。

CEC系统主要由协同交战处理器（CEP）、数据分发系统（DDS）和相控阵天线组成。CEP的主要功能是融合来自舰队内各平台所有传感器的测量数据，并通过自动栅格锁定、自动识别和航迹相关处理，生成复合跟踪航迹和复合识别数据库。DDS是一个高速通信数据链设备，主要功能是在各平台CEP之间提供数据传输,包括传感器数据和火控数据传输[3]。

1996年初，在夏威夷太平洋导弹靶场附近成功进行了名为“山顶计划”的CEC超视距交战测试[4]，试验使用安装在Kauai岛Kokee山顶经改装后的E-2C搜索雷达，引导同在山顶的MK-74火控雷达捕获目标，利用CEC融合后的复合跟踪数据支持伊利湖号宙斯盾巡洋舰提前发射SM-2防空导弹和实施中制导，在导弹接近超视距目标后由MK-74火控雷达接手照射目标，成功击落靶机，这是美海军历史上首次实现舰艇击落地平线以下的目标。

CEC Block I对协同交战技术发展具有三方面贡献[5]：

CEC Block I为实现远端数据本地化，将网内所有传感器的测量数据在网内实时广播分发，确保每个节点收到相同质量的数据。这种广播式数据分发机制，使得CEC的C波段15 Mbps数据链最多只能支持20个协同节点，限制了CEC的使用范围。2003年，为解决这一关键制约问题，美国海军启动CEC Block II升级计划提案征集工作。

1999年，曾经是约翰•霍普金斯APL实验室CEC设计小组成员的Citrin，作为Solipsyss公司的总裁，将TCN技术介绍给美国海军，希望作为CEC技术升级方案。洛克希德•马丁公司对这项技术持认可态度，与Solipsyss公司合作共同竞争CEC Block II。2002年，雷声公司收购Solipsyss公司。2003年，雷声公司和洛克希德•马丁公司宣布成立小组，联合竞标CEC Block II升级计划，研制费预算达10亿美元。但海军最终选择了基于P3I（Pre-Planned Product Improvement）方法的方案，确保改进后的软件符合开放式架构计算环境（OACE）标准，并先后于2004年和2005年授予雷声公司两份合同[6]。

为实现网络的可扩展性受网络节点数量的影响最小，TCN相对于CEC Block I在设计上进行了以下四个方面改进。

TCN对协同交战技术发展具有六个方面贡献：1）采用面向对象的思想进行系统设计；2）按需数据分发方式，为扩展协同节点数奠定基础；3）具备生成SIP、CTP和COP的能力（提供多层服务）；4）数据传输透明化，数据与处理传输通道解耦合；5）具备与其它通信链/网进行数据交换的能力；6）验证远距离传感器点迹数据融合的可行性。

为压缩信息到火力的转换时间，最大限度把信息优势转换为决策优势和行动优势，2005年，美国国防部发布第5144.1号令，标志美军向网络中心战转型进入实质阶段。

SIAP概念在1998年的美战区防空和导弹防御的顶层需求文档CRD中首次出现。1998年，美国国防部制定了SIAP的开发计划。1999年，美国防部启动联合作战管理指挥控制（JBMC2）项目，实现美军由平台中心战向网络中心战转型，由联合作战司令部（USJFCOM）负责管理。JBMC2将SIAP纳入其30项核心能力进行开发。2000年，USJFCOM专门成立JESSO组织，负责SIAP系统工程的研究工作。

SIAP本质上是提高分布式系统之间的情报融合与态势共享能力，由此需要满足JBMC2对数据互操作性的要求。SIAP的核心是融合实时和非实时数据，形成通用、连续、不模糊的空中目标航迹图像，每个目标只有唯一的一条航迹，并具有作战身份标识信息。SIAP能够使指挥官及时掌握空中战场态势，并综合运用武器资源对抗各种威胁，同时减少对友军的误杀伤风险。

作为最早提出网络中心战概念的美国海军，希望将CEC作为网络中心战装备进行大范围装备。但CEC要成为SIAP的通用解决方案还相差甚远，其贡献主要在于改进数据链路和完善SIAP标准。2003年，美海军在推迟CEC Block II的同时，与JSSEO签署谅解备忘录，合作开发联合航迹管理（Joint Track Architecture, JTM）产品。2005年1月，美海军正式取消原CEC Block II升级计划，使用SIAP系统工程产品进行代替，JSSEO获得6年（FY2004-FY2009）1.6亿美元预算[7]。

2008年，雷声公司成功演示了Jfires（Joint Force Interoperability and Requirements Evaluation SupraCenter)。Jfires是一个多战区、多业务的分析、演示环境和原型系统。雷声公司采用TCN作为SIAP的技术框架，通过复合网络实现标识共享和属性关联，并验证一些新的功能，例如，基于网络的跟踪提示、传感器资源管理、综合火力控制等。从这次试验报道来看，雷声公司没有放弃TCN技术，TCN技术框架通过发这次试验得到验证。

SIAP系统工程对协同交战技术发展具有四个方面贡献：1）引入基于IP体制的P2P通信体制；2）规范SIAP的属性描述，为战场态势统一提供了评估方法；3）建立可裁剪的系统集成架构(IABM)，解决异构平台间的互操作问题；4）从杀伤链构建的角度，进行跨平台火力综合，建立分布式决策机制，为构建“分布式杀伤链”奠定基础。

2007年，RDT&E计划明确CEC将于2010年开始向SIAP方案转换。在2008年爆发全球金融危机背景下，为削减军费预算，2010年，奥巴马政府取消了海军提出的用于将CEC设备向SIAP装换的60亿美元预算（同时取消的还有F-22等先进装备采购计划等）。同年，美国海军将CEC作为协同数据链并入NIFC-CA项目。

NIFC-CA早期称为OCMD（Overland Cruise Missile Defense），1996年由陆地航空器项目JLENS（Joint Land Attack Cruise Missile Defense Elevated Netted Sensor）资助，主要解决对低空陆地巡航导弹超地平线监视和拦截问题。2002年，OCMD项目被重塑成NIFC-CA，项目目标扩展到对地平线外飞机和反舰巡航导弹的监视和拦截[8]。2010年，CEC并入后，NIFC-CA被分解为空中、海上和陆地三条“分布式杀伤链”。2015年3月，正式部署“罗斯福”号航母打击群，实现初始作战能力，标志着美海军编队网络化协同防空作战体系更趋完善。

NIFC-CA系统是CEC的进一步延伸与扩展，基于多平台协同探测、协同指控、协同制导等三大技术，实现传感器网、火控网、武器网的三网合一，构建“分布式杀伤链”。

2009年5月，NIFC-CA使用E-2D制导SM-6成功进行了目标超地平线拦截。2014年6月，NIFC-CA实现舰-舰协同制导SM-6对反舰巡航导弹进行超地平线拦截。2016年1月，完成SM-6在NIFC-CA支持下进行远程反舰试验。2016年9月，在白沙试验场，利用一架F-35B作为前置传感器，制导SM-6成功拦截超视距来袭目标，这是NIFC-CA系统首次利用E-2预警机以外的空中平台传感器进行火力引导打击。

从美军协同技术发展过程来看，需要重点解决三方面问题：异构平台资源集成问题、态势统一问题以及协同机制问题。

体系装备需要集成现役、在研和未来规划装备，这些装备由不同厂商在不同时期设计，除了软硬件接口不同外，内部控制流和信息流各不相同，相同功能模块在不同平台实现也不相同，也就是造成“互操作”问题。要对不同平台的传感器、武器和通信等资源进行体系集成，首先必须解决互操作问题，即实现：

为解决这一问题，CEC Block I中在各协同平台嵌入相同的CEP模块，通过接口适配，直接连接所在平台的传感器和武器等资源，解决了异构平台间的互操作问题。但如果协同的装备大范围扩展后，特别是进行跨军种协同，“嵌入”到协同平台的CEP模块可能由不同厂商研制，这些厂商即便遵循相同的标准，但由于对相同功能可能存在理解上的差异，不同厂商研制的CEP模块间仍可能就存在严重的互操作问题。

因此，SAIP系统工程中提出了集成体系行为架构模型（IABM），作为一种平台无关的对等处理模型，由适配层、选项层和核心层组成[9]，如图1所示，其中核心层是所有协同平台都必须具备的功能，选项层则根据平台资源配置和作战任务选装不同功能模块，适配层主要实现与所在平台传感器和武器等资源的接口适配。通过IABM，确保不同厂商研制的CEP模块中的相同功能模块，在输入相同情况下(由P2P保证)，输出相同。2005年，基于IABM的概念演示取得成功。2006年，洛克希德马丁公司在集成IABM的宙斯盾武器系统上成功模拟导弹防御作战过程。这是通过集成IABM提供SIAP的武器系统导弹防御作战的首次演示。

图1 IABM理论构型

态势统一是整个协同作战系统的“根基”，是各协同节点行动步调保持一致的基准参考。CEC Block I中在所有武器节点共享一致的火控级态势图SIP，解决以往武器“打得远”，武器配属的火控雷达“看不远”的矛盾问题，是CEC Block I系统的核心功能。SIP的典型特点是目标跟踪精度高、数据更新率高，但覆盖范围小，因此需要与覆盖更大战场范围的通用战术图CTP进行数据交互。由于CTP用于战术指挥决策，其航迹跟踪精度低，数据刷新率低，且航迹存在模糊，一致性差，因此在CEC Block I系统中SIP直接与CTP进行数据交互存在困难，战役、战术层与火力打击层对战场的“认识”可能存在不一致，导致OODA指挥决策环与F2T2EA杀伤链环之间耦合困难。为解决这一问题，SIAP系统工程将CTP进行升级，融合实时和非实时数据，形成通用、连续、不模糊的空中目标航迹图像，每个目标只有唯一的一条航迹，并具有作战身份标识信息，解决战术层与火力控制层之间的态势信息交互问题，实现了火力控制层的状态和执行信息“上传”以及作战决策指令“下达”。

传感器、武器等作战资源网络化后，将作为体系资源根据作战任务进行调用，根据战场变化进行“目标-武器-传感器”的动态配对，构建杀伤链。在实际作战环境下，作战体系内可能同时运行了多条杀伤链，单个传感器可能同时需要承担不同杀伤链、不同阶段的作战任务，存在资源的动态竞争与最优分配问题，需要建立合理的决策控制机制。CEC Block I中虽然实现了“A看B打”模式，但并未深入讨论协同交战的自动决策与控制机制问题。SIAP系统工程针对这一问题对综合火控（IFC）概念进行了深入研究，提出采用P2P对等处理机制，将传感器、武器等作战资源网络化，各节点使用相同的IFC处理器，对相同的输入（SIAP、交战规则和先验知识），产生相同的辅助交战决策，并根据作战态势，自动调整作战方案（直到目标被击落），各节点根据交战决策结果提取本平台的任务执行。SIAP通过IFC概念，建立分布式决策与控制机制，根据杀伤链各环节需求动态选择最优传感器和武器资源，为“分布式杀伤链”构建奠定了基础。

“体系”又称“系统之系统”，是由一组或一系列独立的、起作用的系统在逻辑上集成为更大的系统，提供单个组成系统所不具有的能力。传统单装备对外提供的是功能，例如探测功能、通信功能等，这些功能一般是确定的、具体的。而体系装备对外提供的是作战能力，例如对低空目标的超视距打击能力，需要不断适应新的作战概念、作战目标、作战环境。这种差异导致在研制过程中，体系装备较单装备呈现出“不确定”特性，要将“转化能力目标、理解组成系统及关系、评估性能和能力目标、开发和演进体系架构、监测和评估变变化、处理需求和方案选项、协调体系升级”等七大要素贯彻到体系装备的全生命周期开发中，确保体系能力的不断演进。因此，体系的系统工程方法和经典系统工程方法存在较大差异，具体可参考美国防部2008年发布的《体系系统工程指南1.0版》[10]。SoS SE核心要素及其关系如图2所示。

图2 SoS SE核心要素及其关系

CEC Block I研制之初由于还没有体系的系统工程方法[3]，采用经典的系统工程方法来进行产品设计，导致CEC Block I装备部队不到10年，因无法满足新的能力需求而不得不考虑寻求全新的TCN方案来替换原来的设计方案。空基信息系统应充分吸取CEC Block I的经验教训，从建设初期就采用体系的系统工程方法开展论证、设计、研制和试验工作，将体系能力的可持续演进作为体系工程的核心要求，贯穿体系建设的始终。

架构决定了系统的基本工作机制，体系架构决定了体系可支持的协同工作机制，从而最终决定了体系的能力可演进范围，因此体系架构是体系装备的“基因”，设计体系装备必须先设计体系架构。体系架构设计的核心需要解决三个问题：一是解决顶层作战任务对底层作战资源的动态调配问题；二是功能的可移植问题；三是解决互操作问题。

针对第一个问题，首先需要确定未来体系整体的能力需求，对体系进行任务分解，确定任务集合。根据体系任务集合，按照F2T2EA杀伤链各环节运行需求，对体系功能自底向上进行抽象和模块划分，形成体系的功能模型集。按照核心层、选项层和适配层对粗颗粒度功能集进行分隔，确定各层功能模块的属性以及模块之间的交互关系，建立层与层功能模块间关联关系，分析信息交互关系与环境之间的变化关系，开展体系能力扩展、升级的评估。

针对“可移植”问题，需要在建立的粗颗粒度体系分层模型基础上，对体系分层架构进一步进行细分，并定义层与层之间接口规范。纵向上，根据业务逻辑，对功能模块进行细颗粒切分，切分原则是上下两层间功能模块没有依赖关系，每一层需要对下一层提供的输出接口进行抽象，使得从底层传感器、武器到顶层应用间的数据接口定义逐步面向任务，从而进一步降低顶层功能模块与底层资源物理实现的耦合。横向上，根据层的功能定位，对功能模块进行进一步优化分割，防止同一层模块功能出现功能重叠，确定同一层功能间的信息交互关系。从业务逻辑角度，建立体系架构内各模块间的信息交互关系视图，定义层与层之间接口标准。

针对互操作问题，需要基于IABM模型驱动架构的设计思想，将不同平台共用的核心功能与具体实现技术分离，解决相同核心功能在不同平台实现的“一致性”问题。分离出来的核心业务一般称为平台独立模型（Platform-Independent Model，PIM），在具体实现中，平台独立模型通过平台专用模型（Platform-Specific Model，PSM）嵌入到各个系统中，实现相同算法在不同软件实现上具有相同的“行为”，从而确保体系的能力的跨平台集成与可持续演进，如SIAP在战术系统上的集成实现方式如图3所示[11]。

图3 SIAP在战术系统上的集成方式

传统开放式架构仅仅是解决单个设备功能的可扩展可升级问题，是体系架构设计的必要条件，但非充分条件。未来空基体系建设，要将空基体系架构设计作为核心工作，首先对体系架构进行验证，从根本上解决异构平台间的互操作、可移植以及能力的可持续演进问题。

在单装开发过程中，原型系统主要在早期研发阶段用于技术概念开发，验证系统功能运行流程，提前释放技术风险。装备完成研制后，通过实际检飞或实弹打靶对装备功能性能边界进行检验。

对于体系装备，对外提供的是“作战能力（或者战斗力）”，由于体系是通过单装的各种组合来形成不同作战能力，体系通常没有固定的装备形态。同时，也很难构建真实的“任务”执行环境（包括自身和对手）来评估体系装备的实际作战效能。因此，相较于单装原型系统，体系原型系统存在以下三点不同。

NIFC-CA的开发过程包括工程研制和能力原型开发两条主线，其中能力原型开发贯穿整个集成试验阶段，“端到端”实弹试验同时对“最小能力集合”状态进行确认，通过能力原型系统在不同能力基线间进行状态传递。未来空基体系建设，需要同步构建空基体系能力开发与验证环境，结合“端到端”实弹打靶试验，通过“仿真试验-实弹测试-仿真试验”迭代，开展杀伤链的集成与验证，对体系作战概念、体系架构的工程可实现性、多平台集成风险、作战能力等进行评估，推动体系能力的快速演进。