基于领域驱动的测控任务评定系统设计与实现

杨德辉，周 淦，李林峰

（华北计算机系统工程研究所，北京 100083）

0 引言

航天测控系统是航天工程的重要组成部分，包括中心机、光学、雷达、遥测遥控等基本单元，主要是对航天飞行器的飞行轨道、状态等进行跟踪测量、监视及控制，同时保障飞行器按照预先设计的状态航行与工作，并完成数据通信等预定任务[1-2]。测控任务是指在测控体系支持下为保障航天器顺利工作,并满足对航天器的跟踪、遥测遥控等技术要求,由测控部门根据航天测控系统编制的一种任务[3]。测控任务评定是在测控任务进行过程中，检测参试设备性能指标、工作状态的稳定性、检验参试设备信息产生、传输、处理、显示的稳定性，检测测控系统长时间运行的稳定性和可靠性[4]。

近年来，随着商业航天快速发展，航天发射频率急剧增加，测控需求日益增多，测控系统设备数目激增且技术复杂程度不断提升，测控管理部门面临着设备管控繁重、评定工作低效、人力资源匮乏、指挥信息获取不便等难题。为此，众多学者开展了大量有关测控任务评定的研究与开发工作。其中，针对单一类型测控设备的评定，通用性差，且不能准确全面检测测控系统完成测控任务的能力[5-6]。此外，目前提出的测控任务评定理论及方法受限于当时的应用场景，存在着一定的不足，不适应于商业航天形势测控任务的快速评定需要[7-9]。与此同时，基于单体架构设计的复杂业务系统，软件建模复杂、难以维护且可扩展性差，即使系统中部分模块存在性能或需求更替问题，也需要对整体进行迭代及维护，可扩展性差[10-11]。因此，测控任务评定系统的少人化、自动化、通用化、智能化，成为亟需解决的问题。

为满足商业航天发展形势需要，提高指挥人员的决策效率和准确率，解决测控任务数据低层次应用、人员工作效率低、系统智能化以及自动化程度低等问题的同时，解决软件系统设计建模复杂、难以维护、可扩展性差等问题，本文通过对测控任务评定业务深入分析，基于领域驱动设计对系统业务领域建模，结合领域模型进行微服务划分，基于微服务架构提出评定航天测控任务评定系统设计方案；最后，结合航天发射测控任务评定业务场景验证了系统设计方案的可行性。

1 系统分析

航天发射测控任务流程包括阶段性联调和任务实战，首先要组织由点到面、从静至动、贴近实战的联调，完成对测控系统是否具备任务状态的检验，然后在确保测控系统具备运行正确、状态稳定、应急处理得当的前提下进行实战任务[3]。

测控任务评定系统建立在现有测控系统基础上，通过与中心计算机、测控指挥系统、测控设备、数据库等进行数据交互，如图1 所示，利用测控系统全面的测量、分析与监视信息以及设备运维信息，基于任务评定要素，实现测控任务联调与实战过程中的自动分析与评定，将从各类数据中挖掘的有效信息及时展示以及传递，提高测控任务联调和实战的评定效率。系统具备基础信息管理、任务信息管理、任务评定及评定显示与干预、评定报告生成审核及发布等功能。

图1 测控任务评定系统图

(1)基础信息管理

将中心计算机、测控指挥系统、测控设备、任务评定规则、评定指标算子、火箭型号、任务弹道、遥测数据、数据源信息等测控系统基础信息抽象为模型,在数据库中通过模型标识进行关联组织和统一存储管理,作为测控任务评定信息与配置的承载容器,也是测控任务评定计算处理的执行依据。

(2)任务信息管理

任务信息管理是在基础信息管理的基础上,根据航天任务文书以及联调目的和实战任务特点,实现对测控任务全周期参与要素的配置，包括多类型联调或任务实战项目中理论弹道配置、各参试设备配置、评定指标体系配置、评定算法的调整、报告模板的编辑、显示样式的配置等。

(3)任务评定及评定显示与干预

以测控指挥系统指令触发启动任务评定计算处理过程,在任务各阶段对测控任务全要素在准备和执行过程中的工作情况进行快速评定，利用不同测控任务产生的测试数据，按照测控任务工作原理和判断方法，对测控任务进行快速评定，生成对联调或实战项目的评定结论，并及时推送。同时，为确保评定的准确性及可靠性，支持岗位人员实时查看评定过程，提供历史任务数据的查询和分析比对功能，可基于工作权限从不同粒度对测控任务评定过程进行人工干预，并通过日志记录干预行为。

(4)评定报告生成、审核及上报

评定报告包括任务阶段节点报告、阶段计划节点报告和联调报告等多种类型，在多人协作工作模式下的评定报告支持岗位人员依据权限分层审核及维护，并将审核后的报告上报给测控指挥系统。

2 领域驱动设计及微服务

2.1 领域驱动设计

2.1.1 领域驱动设计架构

构建复杂业务系统关键问题是如何降低软件设计建模的复杂性，从而提高系统的开发效率，降低软件维护成本，提高系统的扩展性和复用性。软件设计大师Eric Evans 提出的领域驱动设计方法体系近年来成为解决此问题的有效手段[12]，它通过将要解决的业务概念和业务规则等内容提炼为领域知识，然后借由不同的建模范式将这些领域知识抽象为能够反映真实世界的领域模型，来指导业务复杂软件的设计开发，使系统高内聚、低耦合、易扩展、易维护。

领域驱动设计提供了系统拆分的一种理念和真实世界的表示方法。它的特点是分层架构、职责划分和易复用。分层架构采用包括表示层、应用层、领域层和基础设施层的四层结构[13-14]。其中，表示层负责解释用户命令以及与用户交互；应用层负责描述系统所要做的工作，并协调领域模型来完成；领域层是系统的核心层，负责表达业务概念、规则以及状态信息；基础设施层为系统和其他层提供通用的技术能力。职责划分可以使领域对象和现实世界业务形成良好的映射关系。

2.1.2 领域模型设计

领域模型位于领域层，是领域驱动设计的核心，是针对特定业务领域内的关键事务以及关系的可视化表示，是为了准确定义需要解决问题而构造的抽象模型，是业务场景到软件系统的映射转化，其目标是为软件系统构建统一的认知[12]。Eric Evans 提出的领域模型核心概念包括实体、值对象、聚合、领域服务、领域事件、限界上下文、领域工厂和资源库等[15-16]。其中，实体和值对象是组成领域模型的基本单元，实体是赋有业务行为且具有唯一标识符的对象，值对象是用于描述特征或属性但没有标识的对象；聚合包含一个聚合根和上下文边界，这个边界根据业务单一职责原则，定义聚合内部应该包含的实体和值对象；领域服务是与领域相关的操作如执行一个显著的业务操作过程，但它并不适合放入实体与值对象中；领域事件作用是引导进一步的业务操作，促使形成完整的业务闭环；限界上下文用来定义领域模型中子领域的边界。

领域模型设计的步骤[15]如下：

(1) 根据业务特点考虑业务流程关键节点或功能模块边界因素，按领域逐级分解为大小合适的子域；

(2) 对每一子领域的业务场景深入分析，明确业务场景中的领域概念；

(3) 分析领域概念，识别领域概念的属性和行为，明确实体、值对象；

(4) 根据实体的关联性定义聚合，找出聚合根，为聚合划定限界上下文；

(5) 识别领域服务和领域事件；

(6) 根据业务、限界上下文、领域服务以及领域事件之间的依赖关系确定领域模型。

2.2 微服务

微服务架构是为了软件系统易扩展且富有弹性，它是将一个单体程序划分为模块集合，每个模块运行在单独的进程中或不同的机器上，模块间通信采用轻量级通信机制，模块集合通过集中式的方式进行管理[17]。每个模块可以使用不同的数据存储手段，被独立设计、实现和运行，实现模块之间故障的隔离，提供软件系统的可用性、可扩展性以及可维护性。

在对系统进行高质量微服务架构设计时，需遵循高内聚、松耦合、以业务为中心、弹性设计、日志与监控、自动化等原则[18]。因此，微服务基础框架需提供注册、配置与管理、通信等功能。同时，为提升系统架构的健壮性和稳定性，需对整体增加容错机制和负载均衡等机制。

2.3 领域驱动设计和微服务的结合

领域驱动设计的目的是实现各业务领域内的高内聚，微服务是通过拆分的手段实现业务领域间的低耦合，领域驱动设计与微服务结合，用领域驱动设计对业务领域进行逻辑划分，用微服务对系统进行物理拆分，从而提供一种应对复杂业务系统落地的高效解决方法[19]。

领域模型设计过程中领域被拆分为多个子领域，一个领域相当于一个问题域，拆分的过程就是将大问题分解为小问题的过程，每个子领域模型都有它对应的限界上下文，限界上下文就是设计和划分微服务的主要依据。在领域驱动设计的分层架构中，领域层的业务逻辑以微服务的方式实现，应用层负责协调、组合、调用微服务，而微服务之间数据交互可以采用领域事件驱动机制。

3 系统设计

3.1 系统领域驱动模型

结合领域驱动设计理论与微服务特点，设计测控任务评定系统领域驱动模型如图2 所示。

图2 评定系统领域驱动模型图

表示层传递用户信息，并完成信息交互逻辑，主要包括任务数据的接收、评定过程以及结果展示；应用层负责领域模型的调度和派发任务；领域层为系统的核心层，负责表达测控任务评定业务的概念、规则以及状态信息，通过将软件中最重要的业务规则进行剥离，抽象在领域层，使得业务逻辑与应用层和基础设施层等代码分离，实现业务逻辑与数据分离；基础设施层为其他层提供通用的技术能力和层间通信，以及领域层的持久化机制。

3.2 系统设计

对系统进行设计，首先进行业务领域建模，领域建模可以降低软件与现实世界之间的差距，用真实的业务概念划分职责；其次，依据业务领域模型的限界上下文，进行微服务的设计和识别；最后，基于微服务架构实现微服务。系统设计如图3 所示。

图3 系统设计图

3.2.1 业务领域建模

首先，对系统业务进行梳理，找出所有的业务对象，根据业务特性确定业务对象中实体与值对象；然后，从实体集合中找出聚合根，即拥有独立的生命周期以及全局唯一标识的实体，将存在紧密逻辑关系的聚合根、实体以及值对象划分到一起形成聚合；然后，集成领域事件流转中产生业务行为的一个或多个聚合根所在的聚合，形成限界上下文。

3.2.2 微服务识别和设计

基于领域驱动设计拆分微服务的主要依据是限界上下文，微服务拆分遵循的原则包括最小完备原则、稳定空间原则、单一职责原则，业务领域模型可依据以上原则粒度细化为若干微服务。基于此，本系统的主要业务微服务模块包括：基础信息处理服务、任务信息处理服务、任务评定服务、评定显示服务、报告生成服务、报告审核服务、信息发布服务、评定过程控制服务等。

微服务模块可独立开发和维护，从而提高系统开发效率，降低软件维护成本。同时，系统中具有相似功能的模块统一封装成可复用的公共服务，为业务服务提供支撑，包括通信服务、协调服务、文件服务等。其中，协调服务能够根据业务需要，通过组合若干独立服务的方式，快速响应需求变化，提高了系统可扩展性及复用性。

3.2.3 微服务实现

为满足系统可靠性、迭代效率、易扩展及易维护等需求，采用微服务架构实现。微服务架构主要包括服务网关和服务管理两方面。

服务网关是以统一的地址对外提供服务，将外部访问请求地址的流量根据适当的规则路由到内部集群中正确的服务节点上，实现对后端服务的透明访问。此外，在满足基本路由功能的基础上，可以提供安全、认证、授权、限流熔断等功能。

服务管理包括服务注册、服务配置、服务监控、负载均衡和日志管理等，负责对系统微服务模块进行集中的组织、协调、监督、维护。服务注册是将系统内提供服务的模块信息注册到公共的组件上，便于调用者及时发现，解决人工维护服务结点复杂的难题。服务配置对系统所有模块的配置文件进行集中管理并动态发布配置信息，为了在不重启的情况下动态刷新服务内部配置项。服务监控从不同维度对微服务模块进行监控，包括部署及运行情况等，便于快速定位问题。负载均衡解决对单个微服务的并发问题，对同时调用同一微服务的多个请求进行科学分配。日志管理负责对微服务执行情况及时记录，在系统故障时，通过日志分析，实现对系统故障的快速诊断。

4 系统业务场景应用

4.1 业务支撑

以航天发射测控任务场景为例，说明测控任务评定系统设计方案的可行性，如图4 所示。

图4 测控任务评定系统应用图

4.1.1 场景说明

航天发射测控任务整体业务流程包括两个部分。首先，在任务前，根据任务文书，制定任务阶段及阶段目标根据任务阶段目标，指定阶段计划，根据阶段计划，编排阶段计划下的联调项目组合。其次，在任务过程中，测控指挥系统发送任务流程指挥指令，测控任务参试设备发送状态信息及原始测量信息，测控任务评定依据指挥指令和任务数据，评定每次任务阶段、阶段计划以及联调项目是否完成目标，评定结论反馈给测控指挥系统，辅助测控指挥系统对任务流程做出决策。当达到任务阶段目标或阶段计划目标或联调目的时推动流程继续向下进行，当所有任务阶段、阶段计划、以及联调项目完成后进行航天发射实战任务。

4.1.2 系统应用说明

该任务场景涉及的微服务包括基础信息处理服务、任务信息处理服务、任务评定服务、评定显示服务、报告生成服务、报告审核服务、信息发布服务、评定过程控制服务，如图4 所示。基础信息处理服务是将中心计算机、测控指挥系统、测控设备、任务评估规则、评估指标算子、火箭型号、任务弹道、遥测数据、任务数据源信息等测控系统基础信息抽象为模型,在数据库中通过模型标识进行关联组织和统一存储管理。任务信息处理服务是针对测控任务流程各结点的目的以及特点,实现对各项目参试设备配置、弹道配置、评估指标体系配置、评估算法的调整、报告模板的编辑、显示样式的配置等。任务评定服务是对测控任务数据对当前结点进行快速评定。评定显示服务是在任务评定过程中，根据展示需求对任务数据进行处理。报告生成服务是对测控任务每一结点执行情况生成总结报告。报告审核服务是对系统生成的报告，通过人工层次干预的方式，进行审核调整，形成最终的报告。信息发布服务是对评定过程中挖掘出的有效信息及时传递。评定过程控制服务是记录测控任务各结点的生命周期，对其控制。

4.2 系统验证

通过测控指挥系统对历史测控任务流程指令发送以及数据回放系统对任务数据回放，最大程度地还原实际任务场景，根据测控任务场景验证基于领域驱动的测控任务评定系统的可行性。系统验证共选择了5 次具有不同特点的航天发射测控任务。搭建的实验验证平台如图5 所示。其中，客户端部署在多个终端PC 上，是对系统的服务层返回信息进行集中展示，并提供人工操作的入口。

图5 系统验证平台图

在测控任务前，测控管理部门基于航天任务文书，制定任务阶段、阶段计划，编排调整计划联调项目。用户通过客户端程序入口发送请求，经过接入层身份认证，然后通过服务网关调用服务层的任务信息处理服务对测控任务信息进行配置，接着通过数据层将任务信息持久化。

在测控任务进行过程中，数据回放系统回放历史任务数据，测控指挥系统发送任务开始指令，经过接入层转发，触发评定过程控制服务开启，评定过程控制服务通过任务信息处理服务获取阶段计划、计划联调项目信息构建评定过程控制模型。当测控指挥系统发送阶段计划开始指令时，评定过程控制服务接收指令后，阶段计划节点信息发送给任务评定服务和评定显示服务，任务评定服务和评定显示服务开始接收测控任务设备状态信息，任务评定服务周期发布阶段计划节点评定信息。当测控指挥系统发送联调项目开始指令，评定过程控制服务接收指令后，将联调项目节点信息发送给任务评定服务和评定显示服务，任务评定依据测量信息进行联调项目评定，并周期发送实时评定结果，通过信息发布服务。当测控指挥系统发送联调项目结束指令时，评定过程控制服务通过任务信息评定服务获取联调项目评定结论，并通过信息发布服务发送给测控指挥系统，测控指挥系统依据评定结论判断是否执行下一联调项目；与此同时，报告生成服务启动，在报告生成后，通过报告审核服务完成对项目报告的审核，通过信息发布服务将生成的联调报告发送给测控指挥系统。

4.3 应用成效

本系统建设的主要目标是降低人工依赖，提升测控任务的自动化水平，提高测控任务的评定效率，缩短航天发射任务周期，从而适应高密度航天发射的常态。综合上述系统基于5 次测控任务的验证，达到了以下4 种效果：

(1) 系统满足对具有不同特点测控任务评定的要求，具有良好的通用性；

(2) 系统通过将测控任务评定要素建模，只需依赖少量人力即可对任务进行快速准备；

(3) 系统在测控任务中，通过测控指挥指令触发，自动开启对测控任务数据的实时评定，并周期发布评定结果为测控指挥决策快速提供智力支持，提升了测控任务评定的自动化水平；

(4) 系统在联调、阶段计划以及任务等关键节点结束后1 min 内，自动生成可定制的电子版评定报告，快速形成任务闭环。

因此，本评定系统能够提高测控任务评定的少人化、通用化、自动化以及智能化水平。同时，评定系统遵循微服务原则建设，可以根据商业航天发展新需求，添加或微调相应的微服务模块，方便维护和扩展。

5 结论

近年来，信息技术在商业航天领域飞速发展和应用，航天发射测控任务评定的少人化、自动化、智能化发展势不可挡，本文通过领域驱动设计进行业务领域建模，根据领域模型进行微服务划分，基于微服务架构建设测控任务评定系统，为提升我国测控任务评定效率及自动化水平提供了参考和思路。同时，与传统单体架构的系统不同，基于微服务架构的评定系统高内聚、低耦合，可以通过组合微服务的方法快速响应需求变化，实现系统的易扩展性和复用性，为解决复杂业务系统建模及设计问题提供了借鉴方法。