基于云原生的开放式指挥控制平台构建技术

樊良优，姚小强，王 刚，刘 伟，何 晟

(1.空军工程大学 研究生院，西安 710051； 2.空军工程大学 防空反导学院，西安 710051；3.中国人民解放军63768部队，西安 710051)

0 引 言

博伊德环(Boyd’s Loop，OODA)理论表明，无论采用多么先进的传感器，战场迷雾都不可能完全消除。由于对抗的存在，作战更是在各种不确定的环境下进行最优判断和决策的过程。因此，如何优化判断模型成为重中之重。随着作战理念、 战术战法、 武器系统的持续更新，传统固定流程指挥控制系统无法适应变化，指挥员不得不耗费巨大的精力应对复杂局面，从而造成决策效率低下。当需要集火射击等复杂精准控制时，靠人工实施效果不佳。实际中，面对同等复杂度的战场环境，指挥员的经验对作战成败产生了巨大的影响。因此，如何有效架起指挥员和系统执行之间的桥梁，实现针对不同场景指挥员意图的灵活表达，并使其可以被系统识别和执行，成为指挥控制系统亟待解决的问题。

李德毅院士提出的知识模型和情境数据双驱动的“OODA环”理论，指明指挥员意图和系统的紧密协同是指挥控制系统的重要发展方向，但并未给出具体解决方案。随着微服务技术的发展，特别是云原生技术的成熟，构建灵活、 开放、 流程可定制的业务系统，已在互联网领域取得了巨大的成功。本文正是将OODA作战理论和云原生技术相结合，实现了指挥员意图的灵活表达和被系统执行。此模式下，参谋人员可在战前录入作战策略集，战中指挥控制系统自动依据态势信息匹配策略执行条件，并由指挥员确认后自动执行策略。这样，指挥控制系统实质上充当了“智能参谋”的角色。当面对复杂战场环境时，指挥员仅需完成“选择题”，无需做“综述题”，从而达到解放指挥员的目的。同时，经过实践检验的处理策略，可以在同类系统间灵活流转，保证“判断”模型的持续更新。另外，系统本身提供的基础服务不足时，技术人员可依托云原生平台的弹性，实现服务的快速扩展。基于云原生技术的指挥控制系统从使用和技术两个维度实现了平台的开放性。

1 开放式指挥控制设计

1.1 开放式指挥控制设计原理

开放式指挥控制系统的设计原理如图1所示。指挥员在战前首先对作战方案进行构想，对不同作战场景下的作战策略进行设计； 然后，通过业务流程建模语言对作战策略进行编排，确保作战策略能够以流程化的语言输入指挥控制平台； 最后，针对实际作战场景匹配作战策略，并通过开放式指挥控制平台来执行策略。而开发人员则需要对平台进行开发和测试，基于云原生理论构建微服务化的指挥控制平台架构，能够保证服务间松耦合并且独立部署和运行，为指挥员策略执行提供原子服务调用。同时，开发人员还需要开发一站式的部署、 交付和运维系统，实现原子服务的快速灵活扩展，并保障开放式指挥控制平台能够稳定运行和升级维护。

图1 开放式指挥控制设计原理图

基于云原生理论设计的开放式指挥控制平台具备以下特点：

(1) 准确表达指挥员作战意图

指挥员每次作战意图表达都是对OODA环的执行过程，OODA环各部分是对指挥员作战思路的充分体现。构建开放式指挥控制平台能够实现对指挥员意图的灵活表达，能够将意图准确映射到指挥控制平台，实现意图的流转和被执行。

(2) 指挥员意图流程化

指挥员作战意图能够被映射为指挥控制系统识别和处理的语言或流程，是指挥员作战意图进入系统的关键环节。构建开放式指挥控制平台能够以脚本或者图形化方式提供战术战法的规则化输入支持，构建战法库，从而将指挥员意图以流程化的语言输入指挥控制系统，系统执行相应流程实现作战意图全流程流转和表达，同时还能够支持对多意图的并行执行和多策略解冲突。

(3) 按需快速实现服务扩容

开放式指挥控制平台要求能够对意图以流程化的形式进行编辑，需要对服务进行灵活调用，对其功能模块按照细粒度进行服务划分。其架构必定是微服务化的，且能够对构成意图的原子服务实现灵活扩充，需要借助云原生技术构建开放式指挥控制平台。

(4) 保证服务稳定可靠运行

微服务化的指挥控制平台能够实现灵活扩展、 便捷开发、 服务独立无依赖，但服务化的架构也带来运维难度的提升、 服务成本增加等问题。为满足业务需求频繁变动和系统快速迭代，需要搭建高可用、 高性能、 高并发的一站式开发、 部署和运维系统，以确保系统快速部署、 可靠升级、 稳定运行。

1.2 基于OODA环的意图表达方法

OODA环理论是一种处理不确定性的方法和赢得冲突的策略，能够帮助飞行员在瞬息万变的空战环境中迅速做出决策，从而赢得战场主动权。战场环境中充斥着各种不确定因素，而且指挥员精确观察环境的能力有限，依赖过时的思维模式来应对不断变化的环境时，得出的结果往往不尽人意。指挥员只有根据不断变化的环境信息，借助开放的思维模式及时调整作战意图，才能从复杂的对战中脱颖而出。

判断是OODA环的关键环节，通常受到文化传统、 基因遗传、 前期经验等因素的影响。为进行准确而有效的判断，指挥员首先需要建立判断模型库，将各领域的多种模型包含进去； 然后将观察得到的碎片化信息通过重新组合与判断模型库进行匹配，找出与之适应的判断模型。但由于信息和判断模型之间无法完美匹配，指挥员还需要根据判断做出决策，并在行动中检验决策的正确性。

因此，在任何战场环境下，指挥员每次作战意图的表达都可以体现在OODA的循环过程上。以飞行员驾驶战机为例，其OODA环示意图如图2所示。通常飞行员在战前预先制定判断模型，飞行途中存在没有出现飞机、 突然出现飞机以及敌机突然发射导弹等情况，飞行员会进入相应的判断环节来对当前环境进行判断。如当空中突然出现飞机时，飞行员此时的心理活动可能为是否是敌机、 我机是否被发现、 是否对我机构成威胁以及飞机来袭意图等，需要对其进行判断。在作战中，飞行员时刻对空域环境做出观察，当出现不同空情时，根据模型匹配结果做出不同的判断并付诸行动。战后飞行员根据行动结果对判断模型库进行调整与更新，从而实现作战经验的积累。通过OODA循环的快速迭代实现作战理念和模型的持续更新，实时性表达指挥员的作战意图和思考过程。

图2 OODA环示意图

通常单次执行OODA环并不能得出期望结果，需要指挥员在下一轮循环中对战场环境重新进行观察和判断。通过反馈机制，指挥员及时对判断模型进行调整和更新，以适应不断变化的外部环境。本文通过对OODA循环的观察、 判断和部分行动环节进行流程化描述的方法，对指挥员意图进行灵活表达，提高OODA循环的执行速度和决策效率，从而比对手更快地、 连续地完成OODA循环，来“重置”对手的OODA循环，进而在复杂的作战环境中赢得主动。

1.3 基于BPMN的意图映射执行方法

本文基于业务流程模型注解(Business Process Modeling Notation，BPMN)的工作流模型，将指挥员的作战思路转化为系统可以理解的语言和符号，将OODA的意图表达方法映射到可以被系统执行的流程或脚本。

BPMN是用一组描述业务流程中发生的各种事件的符号，通过在这些符号之间连线来描述一个完整的业务流程。BPMN2.0提供的建模元素及符号主要包括流对象、 连接对象、 泳道和人工信息四类。

BPMN流程图能够将OODA意图表达模型映射到流程流转上来，可以实现指挥员作战意图通过BPMN被执行。BPMN建模按照细粒度将任务流程分解成多个不同层次任务，将任务分解为多个子任务，直到最后不能够被分解，也可以对不同子任务进行组合。开始事件通常被映射为OODA环中的观察环节，用来实现对BPMN流程的触发。流程可以通过网关并行运行多个任务，被映射为判断环节； 还可以由排他网关对流程流向进行选择，映射为决策环节，其决策规则可以按照策略优先级执行或者由人工进行决策。结束事件通常被映射为行动环节。整个OODA环则可以被映射为一个循环事件，用来实现对OODA的循环执行。BPMN中的子流程可以表示为OODA环中的内环，这样循环流程和子流程结合便可以表示为嵌套的OODA环。其中，BPMN中的消息发送和接收事件可以被映射为向下级发送指令或向上级征求意见。用户任务被映射为指挥员对判断进行决策，手工任务被映射为人为参与的一些环节。通过池与道还可以实现不同作战单位共同参与流程的执行。OODA环中对意图进行表达的各个环节，在BPMN中均能找到相对应的流程符号来实现其功能。

按照细粒度划分对作战流程进行BPMN建模，流程图如图3所示，在流程中，每一个任务被拆分成多个细小的子任务，每一个子任务或者组合任务就是一个微服务，都会调用其相关的原子服务或者组合服务，来实现流程的流转。开放式指挥控制平台能根据需要及时对原子服务进行补充，并且保证能够为流程流转持续稳定地提供服务。

BPMN工作流程能够辅助指挥员在信息处理过程中迅速、 精准地做出决策建议。开放式指挥控制平台可以将战术战法按照BPMN流程的规则模式进行存储，利用作战指挥数据库信息丰富的优势扩充BPMN流程库，也支持对流程库存储的战术战法进行读取以用于辅助决策。

图3 嵌套BPMN流程示意图

1.4 开放式指挥控制平台设计

随着业务流程的不断复杂化，流程流转需要调用的服务也在动态变化。为了实现对原子服务进行扩充，保证能够为流程流转持续稳定地提供服务，需搭建基于云原生理论的基础框架供BPMN流程流转运行。云原生应用通常有微服务架构、 敏捷基础设施、 公共基础服务三个要素。

(1) 微服务架构

为解决单体应用耦合性强、 部署效率低、 系统开发维护困难等问题，对平台进行微服务改造。开发一个包含通用功能的微服务基础框架，依据细粒度来对服务进行划分，并支持二次开发和复用，为后续扩展多个微服务应用提供基础能力； 同时，还包含注册中心和配置中心、 认证中心、 网关服务、 服务调用等基础模块。

(2) 敏捷基础设施

为使部署简单快速，基础设施按需伸缩、 弹性扩展，需要利用Docker技术实现容器自动化部署。Docker技术的可移植性、 迅速启动、 隔离特性等特点，有利于降低应用开发的复杂度，提升应用研发的效率。通过Kubernetes实现服务滚动升级和弹性扩缩容功能，支持应用和服务的滚动升级、 版本回滚和扩缩容，允许服务在镜像更新时自动升级，支持多实例的滚动升级，能够通过手动和自动的策略实现容器实例的扩缩容。

(3) 公共基础服务

为使平台安全稳定运行，需要基于平台化的思想，提供一系列公共的、 无关于业务的通用服务，包括服务监控、 链路跟踪、 系统监控、 日志采集等模块。

开放式指挥控制平台构建总体方案如图4所示。本文通过搭建基础资源池容器云平台，借助基于Kubernetes管理的通用底层容器的基础运行环境，包括容器集群、 容器网络等基础环境，提供通用微服务运行调度框架，实现对服务发现、 负载均衡、 故障恢复、 度量和监控的通用能力。同时，构建服务运行所需的通用中间件能力和基础服务能力。通过服务管理平台构建底层运行调度通用能力、 服务运行需要的中间件和基础服务通用能力，形成统一、 稳定、 高性能的基础运行环境和基础服务。借助开源集群管理系统Kubernetes实现服务的弹性伸缩，指挥控制平台可以根据需要灵活对原子服务进行扩缩容，实现系统的灵活扩展和动态伸缩。这样，从用户层面，指挥员可在战前基于系统已有的原子服务，通过BPMN工具灵活构建多种并行执行的决策流程； 从系统层面，当基础原子服务不够时，技术人员可以快速实现原子服务的扩展。

图4 基于云原生技术开放式指挥控制平台架构图

1.5 平台部署和运维

为使指挥控制平台有较快的更新和部署速度，以快速实现系统更新升级，应使用自动化的持续集成和部署工具，实现自动化编译、 自动化测试、 自动化发布。平台部署运维架构如图5所示。

图5 部署运维架构图

实现自动化部署系统需要利用Kubernetes完成容器部署、 目标维护、 自动化扩缩容、 滚动升级等编排工作。通过微服务系统的抽象，提供功能的复用性和上下游依赖的解耦合； 利用BPMN流程编排系统，提供灵活且图形化的流程开发模式； 利用Jenkins自动化流程工具，完成编译、 自动化测试和打包的流程定义； 利用虚拟网络技术完成容器间的网络通信管理。对于网格式的微服务，因为代理模式的网络通信组件的服务逻辑只需要实现本地的Socket通信即可完成复杂网络拓扑的通信，在编写程序时并不需要引用任何网络组件库，也就没有语言的限制。

2 案例验证

为验证指挥员编辑的策略能否被系统成功执行以及开放式指挥控制平台是否具备灵活的二次搭建能力，设计以下集火射击流程案例。

地空导弹进行集火射击通常是指集中两个或多个火力单元在大致相同的时间内对同一批目标进行射击的方法。射击方式分为同时发射、 同时遭遇、 不同时发射或遭遇三种情况。本文选取同时遭遇情形对集火射击进行分析。结合集火射击的特点，首先，依据OODA环理论构建集火射击模型。然后，将模型映射为可视化强、 便于执行的BPMN流程。接着，BPMN流程利用指挥控制平台来实现对服务的调用和执行，并将流程存储至数据库，为实现指挥员战术战法的灵活编辑提供支撑。最后，根据执行效果反馈调整集火射击模型和BPMN流程。集火射击流程一体化建模示意图如图6所示。

图6 集火射击流程一体化建模示意图

作战场景想定为： 红方的保卫要地为机场和指挥所，并对其设置不同的保卫等级； 蓝方分别用巡航导弹、 战斗机、 无人机和轰炸机对红方保卫要地进行攻击。红方的多个远程和近程防空营负责对要地进行保卫并对蓝方来袭目标进行拦截。在作战过程中，指挥控制平台首先输入仿真态势信息至BPMN流程，并对其进行态势融合处理。然后，通过加权方式计算来袭目标的综合威胁度。当威胁度大于某个值时，执行下一步流程。接着，对攻击关系进行判断并计算射击诸元。当指挥员在规定时限内确认攻击指令后，相应的导弹不能被用于新的攻击指令，正在执行拦截指令的红方单位需要等待当前拦截结束后才可以执行下一次拦截。最后，根据是否有足够时间执行下一次发射来判定使用普通射击还是集火射击。如果普通射击时间不足，集火射击能够满足条件的情况下，使用集火射击来保证拦截概率； 如果不能集火射击，继续使用命中率最高的导弹来进行射击。

根据选取的射击策略，发送射击建议指令(包含防空营、 导弹类型、 指挥员决策时间、 导弹发射时间)并展示在界面，指挥员确认后在相应时间发射导弹，指挥员不做确认则不执行发射。如果策略有冲突，指挥员只选择需要执行的策略。

流程图中每个任务为一个原子服务，或是由多个原子服务通过某些规则构成组合服务，通过对属性进行设置可以将流程任务与原子(组合)服务之间进行关联。而使用Camunda(一种工作流引擎)可以将BPMN文件部署为可执行流程，当BPMN文件需要进行修改，只需再次部署即可。同时，Camunda还支持对多张BPMN流程图异步进行部署和运行。当面对复杂的任务场景时，可以对复杂任务场景进行拆分，构建多张BPMN流程图来进行部署和运行，控制各流程开始触发的时间，从而实现复杂任务场景下的作战流程建模。BPMN流程执行图如图7所示。

图7 BPMN流程执行界面

从Camunda的监控页面可以查看流程调用的相关原子服务和流程流转的进度。当流程全部运转完毕，指挥控制平台向指挥员推送拦截策略供其进行选择，还支持将作战策略以流程图的形式存储至流程库供后续流程建模调用。对于流程库中没有的服务则需进行补充，对于流程库已有的任务模块(原子服务)，在建模过程中可以直接对其进行调用，进而提高了流程建模效率。

指挥员确认界面如图8所示。当流程需要对射击策略选择时，系统向指挥员推送相关策略供其进行决策，指挥员确定攻击指令，并将指令传至火力单元执行。

图8 指挥员确定界面

红蓝双方就想定作战场景进行仿真推演，得出多次推演统计结果如表1所示。

表1 仿真推演战况统计

红方采用集火射击的方式在导弹命中概率和作战效率上比采取普通射击方式更具优势，能够提高对要地的保护能力。在导弹发射间隔时间上，流程控制比人为控制效率更高，能够提高控制精准度。采用流程控制的射击策略能够提高决策效率，减轻指挥员负担。但该案例也存在着一定不足，如没有考虑干扰等实际情况的影响，而且特定流程需要经过实际验证才能在系统间复制。集火射击案例证明, 指挥员编辑的策略能够通过开放式指挥控制平台被执行，且可以灵活实现二次搭建。

3 结 论

基于云原生的开放式指挥控制平台可以实现快速灵活的系统扩展、 作战流程及战术战法的灵活编辑、 指挥员作战意图与指挥控制系统的深度交互，为指挥控制系统由封闭走向开放，最后走向智能提供了思路。在可预见的未来，智能化指挥控制必将在人的监督下实现可控智能。智能化指挥控制的研究成果可与本文打造的开放式指挥控制架构相结合，作为作战策略的服务嵌入执行流程，从而实现指挥控制系统由封闭走向开放，再到智能。