基于BPMN 的指挥控制流程建模方法*

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

（1.空军工程大学研究生院，西安 710051；2.空军工程大学防空反导学院，西安 710051；3.解放军63768 部队，西安 710051）

0 引言

传统指挥控制系统流程固化、耦合性强，人机协同能力差。系统更多的是代替人工完成复杂的计算，并没有很好地将指挥员从复杂的决策过程中解放出来。因此，在各类作战演习中，指挥员更多的是基于作战过程积累的经验来进行最后的决策，需要耗费巨大的精力应对复杂局面，导致决策效率低下，而且作战经验难以在指挥员之间进行传递。如何让指挥员作战意图（战术战法）能够以机器可以识别的语言进入系统，实现作战经验的积累和再运用，让指控系统来为指挥员提供辅助决策建议，将指挥员从复杂的决策过程中解放出来，进而提高指挥员决策效率，成为了指挥控制系统向前发展亟待解决的问题。而业务流程建模符号（business process modeling notation，BPMN）的出现为帮助指挥员搭建作战流程模型，推动指挥员作战意图进入系统提供了一种思路。

文献［1］对几种常见的流程建模方法的优缺点进行了分析比较，为流程建模方法的选择提供了很好的借鉴。文献［2］基于云原生理论，从指挥员和开发人员两个维度构建了开放式指控平台，能够按需快速实现服务扩容和保证服务安全稳定运行。文献［3］提出了一种简单易懂、直接支持业务分析员进行计算机仿真和执行的可视化业务流程一体化建模方法。BPMN 不仅定义了流程的元模型和执行语言，解决了流程存储、交换和执行的问题，还为建模人员提供了一套图形化的流程建模标准，为指挥控制流程建模提供了良好的生态。

因为传统单体架构耦合紧密、流程固化、扩展性差，而云原生从设计之初就被部署在云上，其架构必定是分布式的。这也意味着各服务之间是松散耦合和独立自治的，具备灵活扩展和动态重组的特点，为此，本文提出基于BPMN 的指挥控制流程建模方法，支持建模人员在业务层次上自顶向下进行可视化流程建模工作，利用BPMN 的方法将指挥员制定的作战策略映射为系统可以实现的技术模型，通过开放式指挥控制平台来实现对服务的调用和被执行，实现流程的精准匹配和灵活扩展［4-5］。因此，构建的流程模型既便于建模人员理解，也能够被计算机识别执行，实现作战流程一体化建模。

1 指挥控制流程建模方法

基于BPMN 的指挥控制流程建模整体上分为分析问题和解决问题两大部分，需求分析、模型建立、模型仿真和模型优化4 个阶段，其原理图如图1 所示。分析问题部分包括作战策略构想、作战流程分析、作战服务划分、流程模型构建；解决问题部分包括作战流程部署、流程示例启动、实施效果分析、流程模型优化。通过需求来指导流程建模，通过效果分析来优化流程模型，基于BPMN 的流程建模方法增强了流程模型的柔性，提高了流程建模的效率。

图1 指挥控制流程建模原理图Fig.1 Schematic diagram of command and control flow modelling

1.1 基本概念

BPMN 是领先的业务流程建模符号标注，它提供了一套流程建模图形标记，为流程分析人员、技术开发人员和用户之间架起一个可视化的桥梁。可以借助它创建跨多个活动、系统、参与者和交易的流程模型，只需要添加必要实现细节，模型便可以被计算机识别执行。BPMN1.x 仅为表示流程的图形符号，不支持构建元模型，也不支持对数据的存储、交换和对流程的执行；而BPMN2.0 添加了对模型的XML 序列化描述，定义了存储和执行语义，更加成为一种可执行化的语言标准［6-7］。BPMN 常见元素符号如图2 所示。

图2 BPMN 常见元素符号Fig.2 Common element symbols of BPMN

图3 分支流程示意图Fig.3 Diagram of the sequential process

BPMN 提供了一系列建模符号来对业务流程进行描述，BPMN 常用的流程元素有流对象、连接对象、数据、泳道、人工信息等。基于BPMN 的基本及其扩展元素，为流程建模提供了顺序、分支、并行和循环4 种基本结构［8-9］。

顺序流程：用顺序（消息）流来实现流程的流转和消息的传递，表示两个对象的顺序关系。

分支流程：用排他网关实现类似于编程语言中的if-else 结构，Xor_Split 通过判断逻辑条件从多个互斥的输出流中进行选择，Xor_Join 将其融合为一个输出流，如图4 所示。

图4 分支流程示意图Fig.4 Schematic diagram of the branching process

并行流程：并行网关通过And_Split 生成多个并行顺序流，And_Join 用来融合并行执行流信息，待所有并行流程执行完毕，流程流转至下一环节，如图5 所示。

图5 并行流程示意图Fig.5 Diagram of the parallel process

泳池描述的是整个组织，可以划分为多个泳道，泳道具有分层结构。而泳道描述的是流程的参与者，是一系列特定任务的执行者。泳池和泳道定义了流程中的职责，明确了参与者所处环境的组织边界。同一泳池中的不同泳道之间可以进行通信，代表了流程执行中的不同角色。不同泳池之间通常采用消息机制来进行信息的传递。通过引入泳道能够帮助建模人员从宏观层面理解流程搭建思路，实现各参与者之间信息的交互。

任务是指参与者为完成流程定义目标而需要执行的动作，BPMN 通常为每个任务分配一条泳道。常用的任务有服务任务、发送任务、用户任务、业务规则任务、脚本任务、接受任务、手工任务和任务标记等。通过不同的任务来实现流程不同的功能，对技术上可执行的事件进行建模。

事件是指流程执行过程中发生的事情，每个事件通常包含触发事件发生的原因和事件执行导致的结果两个因素。事件包含开始、中间和结束3 种类型，既包含事件的开始、结束和边界条件，也包括每个活动的创建、开始和流转等。

流程通过开始事件和结束事件来触发流程的开始和结束。在流程搭建过程中，任务之间可以通过网关、事件、活动等符号进行流程流向的选择判断。待全部流程任务执行完毕，流程流向结束事件，该流程执行完毕。战术级指挥控制流程如下页图6所示，从图中可以看出流程的执行对象和各参与对象之间的协作关系。

图6 战术级指挥控制系统作战流程图Fig.6 Combat flow chart of tactical command and control system

1.2 流程构建

BPMN 的流程基本及扩展元素能够完整地描述整个指挥作战策略，满足指挥员搭建作战策略流程的需要。基于BPMN 的流程架构具备以下特点。

1.2.1 作战流程可定制

从流程设计方面来讲，流程建模人员可以根据需要，灵活构建多个流程或子流程来实现流程可定制；从流程实例方面来讲，流程建模人员可以通过人工干预流程执行方式，增加或减少流程参与者和流程环节来实现流程可定制；从二次开发方面来讲，针对特殊的场景带来流程变化，流程建模人员可以通过业务系统对流程进行二次开发来实现流程可定制［10］。

1.2.2 作战流程模块快速构建

流程架构提供流程、表单、代办的统一设计、执行和存储，使得指挥控制系统对接流程架构后，只需要专注作战逻辑和数据处理，就可以获得流程架构提供给指挥控制系统的所有功能。

BPMN 流程图能够将指挥员作战意图通过流程映射到表达模型上来，实现指挥员作战意图通过BPMN 被描述和执行。BPMN 建模按照细粒度将体现指挥员意图的任务流程分解成多个不同层次任务，将任务分解为多个子任务，直到最后不能够被分解。

对于确定的流程任务，建模人员需要通过BPMN 建模器来对流程进行建模，多个开源的业务流程建模引擎都提供了流程建模所需的建模器，方便用户对流程进行构建。BPMN 建模器提供了BPMN 常用的流程元素，通过类似于画图软件的方式用箭头将各个活动模块进行连接，需要设置各个模块的名称、类型定义、ID、接口信息和属性，确保流程能够完整执行，数据流能够正常传递。流程建模器还提供给流程添加标注，创建DMN 决策表等功能，支持一键部署和启动实例，提高了流程建模的可视化能力和建模效率。

2 云原生模式的流程执行方法

对于构建好的流程模型，需要借助BPM 平台来进行部署和执行。市场上常见的两款开源BPM 工作流引擎为Activiti 和Camunda（Zeebe），如表1 所示。Activiti 项目是一项新的基于Apache 许可的开源BPM 平台，支持新的BPMN 2.0 标准，可以将复杂的业务流程从业务系统中抽离出来，使用BPMN2.0 建模语言来进行定义和被执行，可以提高系统的鲁棒性，并且降低了系统开发维护成本［11-12］。Activiti 在单体架构中表现优异，但无法适应当下微服务的场景。而Camunda 作为专门为微服务打造的工作流引擎，支持发布- 订阅交互模式，支持横向扩容和容错机制等，能够解决超大规模的微服务编排问题。本文选择Camunda 工作流引擎来对构建好的流程模型进行仿真验证。

表1 两款常见工作流引擎性能对比Table 1 Engine performance comparison of two kinds of common workflows

表2 保卫要地想定Table 2 Scenario of defending strategic locations

表3 红蓝双方武器想定信息Table 3 Scenario information of the weapons of the red side and the blue side

2.1 流程部署执行

构建好的流程文件通过bpmn 格式进行存储，通过部署程序可以将BPMN 文件部署为可执行流程，XML 格式被解析并转换为流程定义图结构，由流程引擎负责执行。部署完成后，每次启动实例，便可以实现一次对服务的调用，来实现流程的流转过程。对于实例化的流程，通过监控页面，可以观察流程是否部署成功，实例是否正常启动，还可以观察流程的流转路径以及流程执行过程中的各个服务的接口参数。

2.2 服务调用

分布式流程引擎（Broker）不执行任何业务逻辑，只负责处理客户端发送的指令，维护运行中流程实例的状态，并将任务分配给执行工作流中特定步骤的单元（JobWorker）。Broker 通过对集群进行分区以实现横向扩容，通过复制以实现容错。并且集群中所有节点都承担相同的职责，当其中某个节点不可用时，节点的任务会被重新分配到网络中其他节点。指挥控制流程执行框架如图7 所示。

图7 指挥控制流程执行框架图Fig.7 Executive framework diagram of command and control flow

客户端是嵌入到应用程序（执行业务逻辑的微服务）的库，用于跟Zeebe 集群连接通信。客户端通过基于http/2 协议的gRPC 连接到Zeebe 网关，而客户端应用程序支持以不同的开发语言进行开发。在客户端中，JobWorker 每隔一定时间向代理请求某种类型的作业。如果有一个或多个所请求的作业类型可用，则代理会将激活的作业流式传输给JobWorker。接收到作业后，JobWorker 将执行这些作业，并根据作业是否可以成功完成来发送每个作业的完成或失败消息。在流程执行过程中，每个服务都是自治的，各任务（原子服务）从底层数据库中拉取所需参数并将服务输出结果推送至数据库，供其他服务进行调用。

2.3 服务扩充

当指挥员构建的作战策略（高级策略）不能与指挥控制平台的组合（原子）服务进行兼容匹配时，需要对构成基础策略的原子服务以及资源进行自动化扩缩容。自动化扩容主要有两种方式：一种是在开源容器集群管理系统（Kubernetes）集群中，计算节点因主机资源不足，导致无法继续承载流程服务正常工作或流程服务自动扩容，可以通过kubectl join 方式扩容节点以满足最终服务所需资源。可以将不用的计算节点主机或坏掉的计算节点通过kubectl delete node 方式剔除集群，而在剔除集群之前，需要先将剔除节点上部署的容器服务驱逐，并利用cordon 设置为不可调度，防止其他新的服务调度。另一种是通过Pod 水平自动伸缩HPA（horizontal pod autoscaling），实现流程服务的水平自动扩缩容。当流程服务在高峰期点，达到瓶颈时，通过HPA 可以实现自动扩展，以满足复杂作战场景下（高峰期）的流程执行需求（流程服务自动扩容是建立在计算资源充足的前提下）；当流程服务在低谷期点时，也可以实现自动缩容，以保证资源合理的使用。技术人员负责对构成基本策略的原子服务进行补充，利用微服务架构提高指挥控制平台灵活性和可维护性，实现了指挥控制平台的弹性伸缩、动态调度能力，优化了指挥控制平台的资源利用率。而建模人员只负责从系统中查找原子服务（组合服务）来对由多个基本策略组成的高级策略进行流程建模。

指挥控制平台还支持多张流程图的异步并行执行，或者异步启动多个流程实例。因为在面对复杂的作战场景时，指挥员不可能构建一张完整的战场策略图，每次构建的策略子图表达的只是指挥员的局部作战思路。而通过BPMN 可以实现多张子图的并行执行和相互调用，提高了指挥员策略的表达能力和流程的执行效率。

3 仿真验证

为验证指挥员搭建的作战策略流程能够被指挥控制平台执行，设计区域防空反导案例来进行仿真验证［13-14］。作战场景想定为红方的保卫要地为机场和指挥所，并对其设置不同的保卫等级以及抗毁伤值。蓝方分别用巡航导弹、战斗机、无人机和轰炸机对红方保卫要地进行攻击。而红方的多个远程和近程防空营负责对要地进行保卫并对蓝方来袭目标进行拦截。红方失败的条件是保卫要地被摧毁，蓝方失败的条件是红方摧毁一定数量的蓝方进攻武器。

将作战任务模型按照细粒度进行划分，把任务模型拆分成多个原子服务，再通过某种规则将原子服务连接而成组合服务，而多个组合服务还能构建更为高级的服务，其中，各服务的展开子流程如图8（a～c）所示。底层数据库实时对目标诸元进行获取，指挥控制平台通过循环执行威胁估计、射击诸元解算和目标分配等子流程来对拦截参数进行实时更新，形成实时拦截策略推送给指挥员进行决策。

图8 子流程服务接口图Fig.8 Interface diagram of sub-process services

对特定作战场景完成流程建模后，依托实验室的开放式指挥控制平台和服务器对搭建好的流程进行仿真执行，从监控界面观察到的流程执行情况如图9 所示。

图9 流程执行图Fig.9 Executive diagram of procss

平台在执行流程的过程中，会对初始流程的子流程模块进行调用，并将子流程的执行结果返回至初始流程，然后流程继续向前流转，当数据流流至结束事件节点时，流程执行完毕。流程执行过程中调用的部分子流程服务如图10 所示。

图10 流程执行过程中调用的子流程服务Fig.10 Sub-process services deployed during the executive process of flow

通过监控页面可以观察到流程流转过程中的数据流走向以及各项参数信息，以可视化的方式便于参谋人员进行数据查看和故障排除。某流程的服务执行图如图11 所示。

图11 子流程服务执行图Fig.11 Executive diagram of sub-process services

当流程流转至指挥员确认的用户任务对话框时，弹出指令确认界面，此时需要指挥员对相关指令进行确认后才能执行后续流程节点。指挥员确认界面如下页图12 所示。

图12 指挥员确认界面Fig.12 The confirmation interfaces by commanders

当发射多发导弹对同一目标进行集火拦截时，在导弹发射间隔控制上，利用流程控制比人工控制执行执行效率更高，且具备更高的命中概率。另外，BPMN 建模器支持直接对服务的各项参数进行修改，然后再进行部署运行即可，而不用修改后台执行代码。并且可以根据任务场景需要对服务的子模块进行自定义连接，例如可以将威胁估计和射击诸元解算的位置进行调换，服务的执行顺序也随之进行变换，具备灵活的二次搭建能力，能够根据指挥员意图动态对服务进行调整。

4 结论

现代化战争的指挥控制过程正朝着模块化、动态化和智能化的方向发展，本文提出的基于BPMN的指挥控制流程构建方法依托BPMN 相关技术将指挥控制、流程建模和云原生三者进行了有机结合，有效提升了指挥控制流程建模的灵活性、可扩展性和开放性。但是该方法还存在一定局限性，例如未考虑敌方干扰，对作战场景的想定较为简单，对于复杂环境下的指挥控制流程建模可靠性，以及开源平台的安全漏洞等风险如何控制等问题还有待进一步研究。