CN116166225A - 基于软件定义的任务规划中台架构设计方法 - Google Patents

Abstract

本发明提供一种基于软件定义的任务规划中台架构设计方法，包括：根据软件定义的平面划分方法，将任务规划中台分为应用平面、控制平面和执行平面，执行平面包括业务中台和数据中台；设计业务中台和数据中台的层次结构，以及将业务中台划分为多个业务能力中心，将数据中台划分为多个数据能力中心，每个业务能力中心用于提供各自对应的业务服务，每个数据能力中心用于提供各自对应的数据服务；基于领域驱动设计方法设计业务能力中心的领域模型以及数据能力中心的领域模型。本发明能够实现中台的业务服务能力和数据服务能力的集中管控、灵活编排，提高系统运行效率和复用能力。

Description

基于软件定义的任务规划中台架构设计方法

技术领域

本发明涉及计算机技术领域，尤其涉及基于软件定义的任务规划中台架构设计方法。

背景技术

任务规划是指在任务执行过程中对个体工作状态及使用方法或步骤的规划及安排，遍布于社会生活诸多领域。如在军事领域中，任务规划是根据上级意图，在理解任务、分析判断情况的基础上，依据给定的力量、资源、规则、武器(用于攻击的工具)性能、战场(交战的地方)环境、初始状态、目标状态等约束条件，按照规范的组织程序，运用科学规划模型和智能算法工具进行计算、分析和推理，产生一系列行动序列，并逐步形成方案、计划和行动指令的持续迭代过程。

任务规划系统是指挥信息系统的重要组成部分，也是研究任务设计、制定计划、指导实践的重要手段。如在军事领域中，现有任务规划系统主要由各军种独立开发，系统研发周期长、重用性差，不同任务规划系统之间难以交互操作，无法满足联合整体需求。

发明内容

本发明提供一种基于软件定义的任务规划中台架构设计方法用以解决现有技术中任务规划系统重用性差，不同任务规划系统之间难以交互操作的缺陷，实现任务规划系统的平台化，提高系统的互联互通互操作能力，提高系统复用能力和资源使用效益。

第一方面，本发明提供基于软件定义的任务规划中台架构设计方法，包括：

根据软件定义的平面划分方法，将所述任务规划中台分为应用平面、控制平面和执行平面，所述执行平面包括业务中台和数据中台；

设计所述业务中台和所述数据中台的层次结构，以及将所述业务中台划分为多个业务能力中心，将所述数据中台划分为多个数据能力中心，每个所述业务能力中心用于提供各自对应的业务服务，每个所述数据能力中心用于提供各自对应的数据服务；

基于领域驱动设计方法设计业务能力中心的领域模型以及数据能力中心的领域模型；

其中，所述应用平面用于为前台应用提供接口和管理所述前台应用；

所述控制平面用于对所述业务能力中心和所述数据能力中心进行注册，所述控制平面还用于根据接入的前台应用对所述业务能力中心和所述数据能力中心进行编排和组装。

可选地，所述将所述业务中台划分为多个业务能力中心包括：

根据业务领域，对所述业务中台的能力进行划分，得到所述业务能力中心。

可选地，所述设计所述业务中台的层次结构包括：

根据每个所述业务能力中心对应的业务层级或业务对象，将所述业务中台划分为如下业务层：业务实体层、业务协作层和业务活动层，每个业务层包含多个业务能力中心；

所述业务实体层，用于对静态业务实体进行管理；

所述业务协作层，用于对协作业务进行管理；

所述业务活动层，用于对核心业务进行管理；

其中，所述静态业务实体、所述协作业务和所述核心业务是预先定义的。

可选地，所述基于领域驱动设计方法设计业务能力中心的领域模型包括：

对各个所述业务能力中心对应的业务领域进行划分，获得各个所述业务能力中心包含的业务子域；

根据所述业务子域确定各个所述业务能力中心的界限上下文；

基于所述界限上下文，构建各个所述业务能力中心对应的领域模型。

可选地，所述数据中台的层次结构包括数据资产层、数据工具层和数据仓储层；

所述数据仓储层用于存储数据资源；

所述数据工具层用于为所述数据资产层提供数据处理工具、标签以及管理所述数据资产层产生的数据资产；

所述数据资产层用于获得数据资产以及确定数据资产对应的标签。

可选地，所述数据资产层包括数据源模型、主题域模型、标签模型和算法模型；

所述数据源模型用于获取数据资源；

所述主题域模型用于对所述数据资源进行筛选和加工从而形成数据资产；

所述标签模型用于确定数据资产对应的标签；

所述算法模型用于提供计算功能，所述计算功能至少包括以下一种：计算预警数据、计算推荐数据或数据统计。

可选地，所述数据工具层包括数据开发工具、数据资产管理工具、标签工具和智能平台；

所述数据开发工具用于采集原始数据；

所述数据开发工具还用于对所述原始数据进行处理，获得数据资源；

所述数据资产管理工具用于对数据资产进行管理；

所述标签工具用于基于标签配置规则生成标签；

所述智能平台用于提供智能计算工具。

第二方面，本发明还提供一种任务规划中台，所述任务规划中台是基于第一方面所述的基于软件定义的任务规划中台架构设计方法设计得到的。

第三方面，本发明还提供一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现如第一方面所述基于软件定义的任务规划中台架构设计方法。

第四方面，本发明还提供一种非暂态计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现如第一方面所述基于软件定义的任务规划中台架构设计方法。

本发明提供的基于软件定义的任务规划中台架构设计方法，任务规划中台是从多个相似的前台应用共享的需求中产生的，前台应用与任务规划中台建立联系，业务中台围绕以任务规划为核心关联的领域组成，任务规划中台能够支撑多种业务场景，实现任务规划系统的平台化，将多业务场景的前台应用统一到一个任务规划中台中，基于本发明实施例提供的任务规划中台的设计方法得到的任务规划中台(以及基于任务规划中台构建任务规划系统)具有以下优势：一方面，不同任务规划系统(如海、陆、空等不同任务规划)采用统一的中台架构，可以实现不同任务之间互联互通互操作，提高系统运行效率，促进能力生成。另一方面，不同任务规划系统能够实现资源共享、能力复用、统一保障，有利于提高系统复用能力和资源使用效益。

附图说明

为了更清楚地说明本发明或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本发明实施例提供的基于软件定义的任务规划中台架构设计方法的流程示意图；

图2是本发明实施例提供的任务规划中台的结构示意图；

图3是本发明实施例提供的业务能力中心示意图；

图4是本发明实施例提供的业务中台的架构示意图之一；

图5是本发明实施例提供的用户中心模型设计示意图；

图6是本发明实施例提供的资源投送领域划分示意图；

图7是本发明实施例提供的装备投送子域的限界上下文划分示意图；

图8是本发明实施例提供的装备聚合模型的设计示意图；

图9是本发明实施例提供的业务中台的架构示意图之二；

图10是本发明实施例提供的数据中台的架构示意图；

图11是本发明实施例提供的电子设备的结构示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将结合本发明中的附图，对本发明中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

下面结合图1－图10描述本发明实施例提供的基于软件定义的任务规划中台架构设计方法。

图1是本发明实施例提供的基于软件定义的任务规划中台架构设计方法的流程示意图，如图1所示，本发明实施例提供一种基于软件定义的任务规划中台架构设计方法，包括：

步骤110，根据软件定义的平面划分方法，将所述任务规划中台分为应用平面、控制平面和执行平面；

所述应用平面用于为前台应用提供接口和管理所述前台应用；所述执行平面包括业务中台和数据中台，所述业务中台包括多个业务能力中心；所述控制平面用于对所述业务能力中心和所述数据能力中心进行注册，所述控制平面还用于根据接入的前台应用对所述业务能力中心和所述数据能力中心进行编排和组装。

具体地，按照软件定义的平面划分理念将任务规划中台分为执行平面、控制平面和应用平面。本发明实施例的任务，可以为作战(两个不同队伍之间的冲突解决方式)任务或军事任务。软件定义是指通过虚拟化及其应用编程接口(Application ProgrammingInterface，API)实现调用硬件的可操控成分，以实现硬件的按需管理。具体地，软件定义可以将计算机中的计算、存储、网络等资源，抽象为系统软件对虚拟资源进行管理和调用。在此基础上，用户可编写应用程序，访问资源所提供的服务，进而改变资源的行为，满足应用对资源的多样需求。可选地，所述接入的前台应用是基于用户需求确定的。

步骤120，设计所述业务中台和所述数据中台的层次结构，以及将所述业务中台划分为多个业务能力中心，将所述数据中台划分为多个数据能力中心，每个所述业务能力中心用于提供各自对应的业务服务，每个所述数据能力中心用于提供各自对应的数据服务；

具体地，设计所述业务中台和所述数据中台的层次结构是指对业务中台和数据中台进行分层，获得层次结构，每层可以包括多个能力中心(业务能力中心或数据能力中心)。

每个所述业务能力中心用于提供各自对应的业务服务，每个所述数据能力中心用于提供各自对应的数据服务，是指业务能力中心和数据能力中心能够为接入的前台应用提供对应的业务服务和数据服务。

示例性地，业务中台包括业务能力中心1、业务能力中心2和业务能力中心3，数据中台包括数据能力中心1、数据能力中心2和数据能力中心3，每个能力中心所提供的的服务不同，比如数据能力中心1可以提供数据存储服务，数据能力中心2可以提供数据计算服务，业务能力中心1可以提供环境分析服务；接入前台应用A需要数据存储服务和环境分析服务，则可以由数据能力中心1和业务能力中心1向前台应用提供对应的服务。应理解，以上是为便于理解进行的举例，不应对本申请构成任何限定。

步骤130，基于领域驱动设计方法设计业务能力中心的领域模型以及数据能力中心的领域模型；

具体地，领域驱动设计(Domain-Driven Design，DDD)是指根据领域专家的输入对软件进行建模以匹配该领域的软件设计方法。通过DDD方法设计业务能力中心的领域模型以及数据能力中心的领域模型，能够在复杂领域中，将业务的复杂性和技术的架构的实现解耦开来，通过边界的划分方法构建出清晰的领域和应用边界，让架构更加容易的进行演进。

一种可能的实现方式中，图2是本发明实施例提供的任务规划中台的结构示意图，如图2所示，本发明实施例提供的任务规划中台包括应用平面、控制平面和执行平面，所述任务规划中台能够与前台应用相连接。前台应用可以包括多种不同的军种所需的应用，如陆、海、空、网络、电磁等不同领域对应的前台应用，每种军种所需的应用中又可以包括多种不同的方向的前台应用，如数据分析、天气分析等。执行平面主要负责共享业务能力的抽象和各个能力中心(包括业务能力中心和数据能力中心，以下可以将两者合并简称为能力中心)的稳定运行，并提供各种灵活的业务引擎(如能力中心)；控制平面主要负责业务逻辑的按需组装与灵活编排；应用平面为多业务场景的前台应用提供统一的入口和对前台应用管理。

下面对本发明实施例中的各个平面进行介绍。

执行平面。主要包括业务中台和数据中台，共同构成任务规划中台的内核。业务中台和数据中台分别由业务能力中心和数据能力中心构成(以下可以将两者合并简称为能力中心)，能力中心是可以共享和重用的，能力中心可以被控制平面重复调用。每个能力中心可拆分为多个分布式执行单元。业务中台中的业务能力中心能够在不同的任务中通用，使得业务中台实现了提供任务规划共用业务能力，数据中台提供数据资产共享服务能力。执行平面在保证各能力中心稳定运行的基础上，提供灵活的业务引擎，使中台变得更加灵活。执行单元根据控制平面发送的配置信息，按需加载配置参数和业务规则，再结合业务引擎实现柔性运行。

控制平面。主要负责业务逻辑(即对业务能力中心进行组装和编排的逻辑)的按需组装与灵活编排，提供注册服务、编排服务、调度服务、流程服务等共享能力。执行平面中的各个能力中心包含各种功能服务，每种功能服务对应一个分布式执行单元，各分布式执行单元将能力(可以理解为能够实现的功能或者提供的服务，下同)注册到控制平面中统一的控制中心，由控制平面对分布式执行单元进行集中管理和控制。经过控制平面的组装与编排服务，可产生配置参数、业务规则和业务流程等配置信息。通过这些配置信息可实现控制平面与执行平面的交互，以便根据个性化需求进行灵活组装与编排。

应用平面。为多业务场景的前台应用提供统一的入口和应用管理，通过应用平面，能够为陆、海、空、网络、电磁等不同领域的任务规划前台应用提供统一的接口，使得前台应用能够通过接口接入任务规划中台。接入的前台应用是根据用户需求确定的。

一个实施例中，前台应用可以包括对地打击任务规划系统、对海打击任务规划系统、防空反导任务规划系统、远程火箭炮任务规划系统等等。前台应用包括多领域任务，不同前台应用针对不同的任务。对于不同的任务，只需在任务规划中台的基础上开发不同的前台应用。前台应用通过应用平面接入任务规划中台。控制平面根据某个任务的业务逻辑，控制不同能力中心的执行顺序、数据流向等。

假设对地打击任务规划系统通过应用平面接入任务规划中台，控制平面可以根据对地打击任务规划系统的业务逻辑，生成配置参数、业务规则和业务流程等配置信息。控制平面将配置信息发送至执行平面，对应的能力中心或分布式执行单元按照配置信息加载配置参数和业务规则运行。业务逻辑可以包括如需要调用的数据能力中心(或者数据能力中心的分布式执行单元)的数据流向，以及需要调用的业务能力中心(或者业务能力中心的分布式执行单元)的执行顺序等。

本发明实施例提供的基于软件定义的任务规划中台架构设计方法，任务规划中台是从多个前台应用共享的需求中产生的，前台应用与任务规划中台建立联系，业务中台围绕以任务规划为核心关联的领域组成，任务规划中台能够支撑多种业务场景，实现任务规划系统的平台化，将多业务场景的前台应用统一到一个任务规划中台中，基于本发明实施例提供的基于软件定义的任务规划中台架构设计方法得到的任务规划中台(以及基于任务规划中台构建任务规划系统)具有以下优势：一方面，不同任务规划系统(如海、陆、空等不同任务规划)采用统一的中台架构，可以实现不同任务之间互联互通互操作，提高系统运行效率，促进能力生成。另一方面，不同任务规划系统能够实现资源共享、能力复用、统一保障，有利于提高系统复用能力和资源使用效益。本发明能够实现中台的业务能力和数据服务能力的集中管控、灵活编排，提高系统的复用能力和运行效率。

下面，对上述步骤在具体实施例中的可能的实现方式做进一步说明。

如图2所示，位于执行平面的业务中台和数据中台是提供任务规划业务机制和数据资产共享服务能力的主体。通过对业务和数据进行抽象，设计领域模型，形成任务规划业务所需的一系列能力中心，支撑任务规划前台应用的流程化、标准化、科学化、自动化和定制化，并且提供数据采集、过滤、清洗、建模、加工、应用以及数据资产管理等服务能力，实现基于数据的辅助决策、方案筹划与计划制定。任务规划中台的能力中心的应用平面为前台应用提供的接口服务有多种形式，如API编程接口形式的服务，以及可视化人机界面形式的服务等，在领域范围内具有通用性和重用性。在软件定义任务规划中台总体架构设计的基础上，需要进一步开展业务中台和数据中台架构设计。

可选地，所述方法还包括：基于领域驱动设计方法规划所述业务中台的架构。具体地，采用领域驱动设计(Domain Drive Design，DDD)方法，围绕业务对象、业务能力、业务规则、业务流程、业务配置和业务隔离等方面，详细设计业务中台的架构，获得基于微服务的、用于任务规划的业务中台架构，形成覆盖任务规划业务流程的一系列能力中心。微服务是一种软件架构，是指把一个大型的单个应用程序和服务拆分为多个的微服务，本发明实施例中将业务拆分为多个业务能力中心，每个业务能力中心能够实现一个或多个微服务。微服务可以扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议。

可选地，设计所述业务中台和数据中台的架构包括划分能力中心和领域模型设计两个步骤。应理解，此处的划分能力中心包括纵向切分和横向分层，纵向切分是指抽象出业务能力中心和数据能力中心，横向分层是指获得层次结构。

划分能力中心的目的是通过业务拆分来降低系统的复杂性，通过业务能力共享来实现可重用性，通过服务化来实现业务响应的敏捷性，通过全局一致的数据模型来消除数据共享的壁垒。为了实现上述目标，本发明实施例在构建任务规划业务中台时，采用基于微服务的分布式体系架构，利用DDD方法进行领域模型设计，按照业务领域划分边界，并且要求每个能力中心都必须是一个完整的业务模型。在进行能力中心划分和模型设计时应遵循以下原则：

一是“高内聚、低耦合”原则。“高内聚”强调的是业务能力中心的业务边界清晰，每个业务能力中心内的业务必须具有高度依赖性；“低耦合”强调的是能力中心之间的业务隔离性，尽可能降低相互之间的依赖程度。

二是数据完整性原则。该原则是“高内聚、低耦合”原则在数据模型中的具体体现，主要强调数据模型的全局一致性，以确保数据的真实性、正确性、有效性、可访问性和完整性。

三是聚焦业务原则。能力中心是承载业务逻辑、沉淀业务数据、产生业务价值的基本业务单元。单纯从技术层面抽象出来的共享服务，如技术层面的共享服务，如存储资源管理、网络资源管理、传感器资源管理，以及容器服务、容器管理服务、大数据存储服务、大数据计算服务、大数据采集服务、分布式缓存服务、消息服务、告警服务等，一般不作为业务中台的能力中心，而应该在技术平台中考虑。具体地，技术平台是指在中台之外用于提供技术支持的平台，技术平台在逻辑上位于中台的下一层。完整的系统架构从上到下可以包括：前台应用、中台、技术平台、基础设施。

四是循序渐进原则。服务化体系架构是一种敏捷实践，业务中台建设不是一次性“交钥匙”工程，应当采用小步快跑的方式逐步扩展和完善，从而降低建设风险和难度。

本发明实施例提供的基于软件定义的任务规划中台架构设计方法，将多业务场景中的各个整体任务拆分为多个业务能力中心，能够降低任务规划系统的复杂性；通过多个业务能力中心，能够将可复用的公共能力从各个业务场景中分离出来，采用微服务架构模式，通过共享业务能力中心来实现可重用性，示例性地，前台应用A中需要进行气象分析，前台应用B也需要进行气象分析，可以确定气象分析业务能力中心，前台应用A和前台应用B都可以共享气象分析业务能力中心，实现业务能力中心的可重用性；通过服务化来实现业务响应的敏捷性；各个业务服务中心能够互相共享输出值等数据，并且都可以从数据服务中心中调用数据，从而实现通过全局一致的数据模型来消除数据共享的壁垒。

下面以业务能力中心为例，介绍如何进行能力中心划分和领域模型设计。

一、划分业务能力中心：

可选地，所述将所述业务中台划分为多个业务能力中心包括：

根据业务领域，对所述业务中台的能力进行划分，得到所述业务能力中心。

具体地，在遵循上述原则的基础上，本发明实施例采用纵向切分与横向分层相结合的方法进行业务中台的业务能力中心划分。

对于根据业务内容确定多个业务能力中心，是指按照任务规划业务领域和业务流程，将业务内容进行纵向切分，并进行抽象、归类、推演，形成业务上相对独立、技术上含有一个或多个微服务的一系列业务能力中心。

一个实施例中，图3是本发明实施例提供的业务能力中心示意图，如图3所示，可以确定出多个业务能力中心：如用户中心、部队中心、装备中心、物资中心、油料中心、情报中心、预案中心、规则中心、任务分解中心、兵力投送(向目标地点输送用于行动的人力资源)中心、目标分配中心、行动设计中心、敌情分析中心、我情分析中心、地形分析中心、气象分析预测中心、海洋分析预测中心、电磁分析中心、社情分析中心、冲突检测/消解中心、任务理解中心、情况分析判断中心、计划/方案制定中心、计划/方案推演评估中心等。

可选地，所述所述设计所述业务中台的层次结构包括：根据每个所述业务能力中心对应的业务层级或业务对象，将所述业务中台划分为如下业务层：业务实体层、业务协作层和业务活动层，每个业务层包含多个业务能力中心；

所述业务实体层，用于对静态业务实体进行管理；

所述业务协作层，用于对协作业务进行管理；

所述业务活动层，用于对核心业务进行管理；

其中，所述静态业务实体、所述协作业务和所述核心业务是预先定义的。

在完成纵向切分的基础上，对于不同的业务领域，根据管理对象的不同性质，自下而上地将任务规划业务中台划分为业务实体层、业务协作层和业务活动层，如3所示。该层次结构既刻画了任务规划业务中台的体系架构，也反映了不同层次能力中心之间的依赖关系和数据交互关系。

图4是本发明实施例提供的业务中台的架构示意图之一，如图4所示，本发明实施例提供的业务中台包括业务实体层、业务协作层和业务活动层。下面结合图4对业务实体层、业务协作层和业务活动层进行介绍：

(1)业务实体层：位于三层模型的最下层，业务实体层由一系列管理静态业务实体的业务能力中心构成，如图4所示，可以包括用户中心、部队中心和装备中心等。静态业务实体是指静态资源，应理解，用户、部队、目标等静态业务实体是客观存在的，中台可通过对静态业务实体的客观存在的数据进行采集和管理即可，不需要对静态业务实体进行再加工。业务实体层用于提供资源的查询、分析和统计等服务。

可选地，所述业务实体层包括以下任一或其组合：用户中心、部队中心、装备中心、弹药中心、物资中心、油料中心、情报中心、目标中心、预案中心等业务能力中心。

用户中心用于管理用户信息；部队中心用于管理部队信息；装备中心用于管理装备信息；弹药中心用于管理弹药信息；物资中心用于管理物资信息；油料中心用于管理油料信息；情报中心用于管理情报信息；目标中心用于管理目标信息；预案中心用于管理预案，预案可以是作战预案。

(2)业务协作层：由一系列支撑类业务能力中心，以及提供资源使用策略的业务能力中心构成，位于三层模型的中间，起到承上启下的作用。如图4所示，业务协作层可以包括规则中心、任务分解中心和专业计算中心等业务能力中心。业务能力中心可由一系列微服务构成，提供相应的功能服务。例如，计算中心可提供兵力需求测算、资源需求测算、战场容量计算、时间测算、目标威胁分析、目标毁伤分析等功能；专业计算中心可提供数学计算、力学计算、光学计算、电磁频谱计算、气象预测计算、水文预测计算、天文计算等功能。可以根据业务需求，不断扩展计算中心和专业计算中心的功能。

可选地，所述业务协作层包括以下任一或其组合：规则中心、任务分解中心、资源投送中心、目标分配中心、行动设计中心、敌情分析中心、我情分析中心、地形分析中心、气象分析预测中心、海洋分析预测中心、电磁分析中心、社情分析中心、冲突检测/消解中心、专业计算中心等业务能力中心。

规则中心用于提供规则约束，规则可以是作战规则；

任务分解中心用于分解任务；

资源投送中心用于计算需要投送的资源；

目标分配中心用于将目标分配给相应作战力量；

行动设计中心用于设计行动计划；

敌情(对手的情况)分析中心用于分析敌方(敌方是指对手)情况，获得敌情信息；

我情(我方的情况)分析中心用于分析我方情况，获得我情信息；

地形分析中心用于对地形进行分析，获得地形信息；

气象分析预测中心用于分析气象，获得气象信息；

海洋分析预测中心用于分析海洋情况，获得海洋信息；

电磁分析中心用于分析电磁情况，获得电磁信息；

社情(社会情况)分析中心用于分析社情，获得社情信息；

冲突检测/消解中心用于消除方案中的时间、空间、频谱冲突等冲突问题，方案可以是作战方案。

计算中心用于兵力需求测算、资源需求测算、战场容量计算、时间测算、目标威胁分析和目标毁伤分析等功能；

专业计算中心用于数学计算、力学计算、光学计算、电磁频谱计算、气象预测计算、水文预测计算、天文计算等功能。

支撑类业务能力中心，以及提供资源使用策略的业务能力中心都属于协作业务，协作业务不一定是军事规划任务不可或缺的部分(或者说主流程的一部分)，业务协作层用于处理协作业务，业务协作层的业务能力中心能够协助处理核心业务的业务能力中心，使得处理核心业务的业务能力中心(业务活动层)的输出效果更好。

(3)业务活动层。由一系列处理核心业务的能力中心构成，位于三层模型的最上层，该层的所有能力中心均可实时调用下面两层(业务协作层和业务实体层)的业务能力中心，以支持核心业务的任务规划业务活动，如图4所示，业务活动层可以包括如任务理解中心、情况分析判断中心、计划/方案制定中心等业务能力中心。业务活动层的能力中心是任务规划活动必不可少的部分，它们为任务规划提供核心业务运行机制。

可选地，所述业务活动层包括以下任一或其组合：任务理解中心、情况分析判断中心、计划/方案制定中心和计划/方案推演评估中心；

所述任务理解中心用于对所述任务进行理解，获得量化后的任务目标；

所述情况分析判断中心用于对当前情况进行分析判断；

所述计划/方案制定中心用于制定计划或方案；

所述计划/方案推演评估中心用于对所述计划/方案制定中心制定的计划或方案进行推演评估。

示例性地，情况分析判断中心可以调用业务协作层中的敌情分析中心、我情分析中心、地形分析中心、气象分析预测中心、海洋分析预测中心、电磁分析中心、社情分析中心，以及业务实体层中的用户中心、部队中心、装备中心、物资中心、油料中心和情报中心，对当前情况进行综合分析判断。

二、领域模型设计：领域模型是对领域内的概念类或现实世界中对象的可视化表示，其专注于分析问题领域本身，发掘重要的业务领域概念，并建立业务领域中概念(数据)之间的关系。

通过划分能力中心，得到任务规划业务中台三层模型，在此基础上，还需要对每个能力中心进行更加详细的领域划分和模型设计。

可选地，所述基于领域驱动设计方法设计业务能力中心的领域模型包括：

对各个所述业务能力中心对应的业务领域进行划分，获得各个所述业务能力中心包含的业务子域；

根据所述业务子域确定各个所述业务能力中心的界限上下文；

基于所述界限上下文，构建各个所述业务能力中心对应的领域模型。

具体地，可以对业务能力中心对应的业务领域进行分析，如根据业务领域之间的关联程度进行划分，得到一个或多个子域业务。可选地，可以通过专家经验、行业习惯等对各个所述业务能力中心对应的业务内容进行业务关联分析。如果所述业务能力中心对应的业务领域无法拆分为子域业务、或者拆分获得子域业务之间的关联程度较高，不再进行划分，将业务能力中心对应的业务领域作为划分结果；所述业务能力中心对应的业务领域拆分获得子域业务之间的关联程度较低，可以将业务能力中心对应的业务划分为多个子域业务(即划分结果)。关联程度是指从功能的角度分析业务领域是否彼此之间的关联和依赖，如果拆分获得子域业务之间存在关联和依赖，可以作为归类的特征，进而将具有强关联的子域业务聚为一类，此时，聚为一类的子域业务作为一个划分结果，获得业务能力中心的划分结果。示例性地，如果两个子域业务的功能需要同时存在；又或者缺少一个子域业务的功能，另一个子域业务的功能是不完整的，则两个子域业务强关联，反之则两个子域业务弱关联。

业务实体层的业务能力中心对应的业务领域相对简单，通常划分后只有一个划分结果，即业务能力中心对应的业务；因此业务实体层的业务能力中心对应的领域模型的结构相对简单，通常只有一个界限上下文。业务协作层和业务活动层的业务复杂，通常划分后会有多个划分结果，即业务能力中心对应的多个子域业务。

限界上下文(Bounded Context)定义了每个领域模型的对应的实体范围，在每个实体限界上下文中确保领域模型的一致性。

下面以业务实体层的用户中心为例，运用DDD方法进行领域模型设计用户中心的领域模型。图5是本发明实施例提供的用户中心模型设计示意图，如图5所示，用户中心对应用户领域，只包含一个用户限界上下文(即实体界限上下文)。用户限界上下文中包括Userentity(用户实体)、Permission entity(权限实体)、Affiliation entity(隶属关系实体)，以及Contact(联系方式)、Address(地址)、AffliType(隶属关系类型)等值对象。将上述实体和限界上下文的值对象聚集在一起，可形成一个名为用户的聚合，其中的Userentity是用户聚合的聚合根。

下面以业务协作层的资源投送中心为例，运用DDD方法进行领域模型设计。与业务实体层的能力中心相比，业务协作层的能力中心相对复杂。本发明实施例以资源投送中心为例进行领域模型设计。图6是本发明实施例提供的资源投送领域划分示意图，如图6所示，资源投送中心对应资源投送领域，基于资源投送中心对应的业务内容，将该领域可进一步划分为人员投送、装备投送、弹药投送和物资投送4个子域，因此可以将资源投送模型分解为4个子域模型进行设计。

图7是本发明实施例提供的装备投送子域的限界上下文划分示意图，下面结合图7，以装备投送子域为例，进行子域模型设计。

首先，运用DDD“化繁为简、分而治之”的方法，以及事件风暴方法，将装备投送子域划分为上下文。然后，如图7所示，对限界上下文中的实体、值对象以及领域服务等模型进行设计，如图6所示。其中，装备限界上下文中包含Equipment repository(装备仓储)、Equipment entity(装备实体)、Handling event entity(事件处理实体)和Sort service(排序服务)；收发方限界上下文中包含Transport customer repository(收发人仓储)、Transport customer entity(收发人实体)；投送任务清单上下文中包含Transport taskentity(投送任务实体)。Equipment entity通过Role(角色)值对象与收发人实体进行关联，Role将收发人实体在一次投送任务中的角色区分开来，确定是接收方，还是发送方。Sort service对Equipment entity提供排序服务，确定装备投送顺序。装备限界上下文通过上下文映射关联到投送任务清单上下文。Handling event entity实体表示Equipmententity实体发生的离散活动，如装备装载、卸载等。

最后，对实体、值对象、聚合等进行详细设计。以Equipment聚合为例，该聚合包含Equipment entity(装备实体)，以及Location(地址)、RouteSpecification(投送任务描述)、Itinerary(行程)、Leg(行程段)、Size(尺寸)等值对象。其中的Equipment entity实体作为Equipment聚合的聚合根，其唯一标识是tracking ID。这里，Location为地址，可被聚合内其他对象引用；RouteSpecification为投送任务描述，包括起点、终点、到达时限等；Itinerary为投送的行程，由行程段Leg值对象组成。

图8是本发明实施例提供的装备聚合模型的设计示意图，装备聚合模型设计如图8所示。

图9是本发明实施例提供的业务中台的架构示意图之二，采用类似的方法，依次对每个业务能力中心进行详细的模型设计，并进行优化和调整，可以得到如图9所示的业务中台体系架构。

综合上述，通过抽象设计，业务中台将多场景前台应用功能相同或相近的服务能力聚合起来，统一标准规范，统一接口，实现业务功能和流程整合，并通过服务聚合实现资源和能力的共享重用，形成覆盖任务规划业务流程的一系列能力中心，支撑新应用和新功能的快速开发与迭代，以满足不断变化的用户需求。任务规划业务中台具有开放性和演化性，可随着应用的推进以及需求的变化不断沉淀和扩展出新的能力中心。

应理解，对于将所述数据中台划分为多个数据能力中心，基于领域驱动设计方法设计数据能力中心的领域模型，参照业务能力中心的设计方法，将业务领域换成数据服务对应的领域即可，此处不再赘述。

可选地，所述数据中台的层次结构包括数据资产层、数据工具层和数据仓储层；

所述数据仓储层用于存储数据资源；

所述数据工具层用于为所述数据资产层提供数据处理工具、标签以及管理所述数据资产层产生的数据资产；

所述数据资产层用于获得数据资产以及确定数据资产对应的标签。

具体地，从任务规划全局业务出发，设计提出主要由数据资产层、数据工具层和数据仓储层组成的数据中台架构。

下面对数据资产层、数据工具层和数据仓储层进行介绍：

1)数据资产层：是数据中台的核心层，它依托在数据工具层之上，由数据源模型、主题域模型、标签模型和算法模型组成。数据资产层的各类模型都具有扩展性，可根据需要增加新的模型。数据资产层可以用于从数据仓储层获得需要的数据资源，调用数据工具层中的数据处理工具以及所述数据资产层中保存的模型对所述需要的数据资源进行计算获得数据资产，数据资产层还可以用于确定所述数据资产对应的标签。

可选地，所述数据资产层包括数据源模型、主题域模型、标签模型和算法模型；

数据源模型用于获取数据资源；

主题域模型用于对所述数据资源进行筛选和加工从而形成数据资产；

标签模型用于确定数据资产对应的标签；

算法模型用于计算预警数据、计算推荐数据和数据统计。

具体地，数据源模型，用于解决数据资源接入问题，数据源模型获取的数据资源主要来源于现有应用系统和业务中台形成的数据湖(Data Lake)，数据湖是数据中台的重要数据来源。数据湖的主要特征是，存储未经转换的原始数据的直接副本。为了支持数据中台建设，应尽可能多地将有用的数据资源存储到数据湖中。

数据源模型获取的数据资源可以包括：情报数据、部队数据、人员数据、装备数据、物资数据、油料数据、目标数据、地理数据、社情数据、兵要地志数据、态势数据、法规数据、方案数据、电磁数据、网络空间数据、气象数据、海洋数据、战例数据等数据。数据源模型可以为多个模型，每种模型用于接入一种数据资源。

主题域模型包括用户、部队、指挥员、专业人才、装备、物资、油料、目标、情报、地理信息、社会文化、政治地理、经济地理、兵要地志、态势、法规、预案、电磁、军用网络、互联网、海洋大气、海洋水文、海洋水声、战例等模型。主题域模型是面向业务领域，对业务过程或维度进行抽象的结果，是经过标准化设计的全局数据模型。应理解，主题域模型可以称为专题数据模型，利用主题域模型对数据资源进行处理，可以形成专题数据。主题域模型承载的数据既包括来自数据湖的外部数据，也包括随着业务活动由前台应用和业务中台产生的内部数据。主题域模型需要长期维护，保持相对稳定，而不轻易变动。

标签模型包括指挥员、部队、装备、弹药、物资、目标、重心、航道、空中走廊、区域等标签模型。标签模型同样需要结合业务过程进行设计。与主题域模型基于业务领域建模有所不同，标签模型是基于业务对象建模的。标签是可重用数据资产的重要载体，可以通过对不同数据资产打标签，实现对数据资产的标识作用，标签是动态演变的，随着时间的推移，标签的数量会逐渐增加。按照实现方式，可以将标签分为事实标签、统计标签和算法标签等类型；按照业务场景，可以将标签分为基础信息标签、偏好标签和价值标签等类型；按照计算模式，可以将标签分为客观标签和主观标签。为了更好地管理和使用标签，需要建立标签类目体系。标签及标签类目体系要始终围绕数据的价值和高效运行来管理和规划数据资产。

算法模型可以包括弹药储备预警、物资储备预警、油料储备预警、卫星过顶预警、战备数据统计、人才推荐等模型。算法模型更加贴近业务场景，在算法模型设计时需要反复推演和验证其适用场景。另外，数据中台的算法模型与业务中台的计算能力中心也有一定的关联。因此，在设计过程中要统筹考虑，明确划分两者的边界，避免重复造轮子。

2)数据工具层：是数据中台的载体，由数据开发工具、数据资产管理工具、标签工具和智能平台组成。数据工具层的各类工具同样具有扩展性，可根据需要增加新的工具。

可选地，所述数据工具层包括数据开发工具、数据资产管理工具、标签工具和智能平台；

所述数据开发工具用于采集原始数据；

所述数据开发工具还用于对所述原始数据进行处理，获得数据资源；

所述数据资产管理工具用于对数据资产进行管理；

所述标签工具用于基于标签配置规则生成标签；

所述智能平台用于提供智能计算工具。

具体地，数据开发工具。包括离线采集、实时采集、数据处理和作业调度等工具。其中，离线采集和实时采集工具实现需求驱动的全域数据采集功能。数据处理工具为企业级全局大数据(规模大、种类多的数据)处理提供统一的计算框架，具备数据发现、多维分析、图计算、数据共享、数据可视化、异常检测、行为审计、安全报警等多种数据处理功能。作业调度工具按照一定的算法，从后备队列中选取某些作业调入内存，并为之创建进程、分配资源，然后将新创建的进程插入就绪队列，准备执行。

数据资产管理工具。包括数据源管理、主题域管理、标签模型管理、算法模型管理、数据资产全景管理和数据溯源管理等工具，可提供集成化的数据资产管理能力。

标签平台。包括标签计算引擎(标签服务)和标签配置管理门户。通过标签配置管理门户进行标签规则配置并提交给标签服务，可得到所需的事实标签、模型标签或算法标签。标签计算引擎用于对数据资产打标签(标识对应的标签)，标签配置管理门户可以为人机交互图像界面，用于与用户交互。

一种可能的实现方式中，可以将得到的标签(如用户输入的标签、计算获得的标签等)输入至标签模型，为标签模型提供标签，再由标签模型将正确的标签与数据资产进行对应。

智能平台。包括深度学习、强化学习和知识图谱等平台。

3)数据仓储层：数据仓储层由一组数据库组成，用于存储部队、装备、弹药、物资、油料、目标、人员、战备等经过规范化处理的全局数据资产(即由数据资产层产生的数据资产)，可支持各种不同业务场景，不但提高了数据的可重用性，而且减少了反复从底层技术平台存取数据而造成的时间消耗。另外，数据仓储层还可用于不断沉淀业务中台产生的业务数据，因为业务中台的建设目标之一就是实现“业务数据化”。当业务中台发现数据中台存有完全相同的业务数据时，可直接从数据仓储层读取，而无需重新进行计算，可大幅提升中台的业务响应速度和数据服务效率。

图10是本发明实施例提供的数据中台的架构示意图，通过上述方法可以获得如图10所示的数据中台，所述数据中台包括数据资产层、数据工具层和数据仓储层；

所述数据资产层包括数据源模型、主题域模型、标签模型和算法模型；

所述数据源模型包括情报数据模型、装备数据模型、人员数据模型、物资数据模型和油料数据模型等；所述主题域模型包括用户模型、部队模型、物资模型、专业人才模型和装备模型等；所述标签模型包括用户标签、部队标签、装备标签、弹药标签和物资标签等；所述算法模型包括弹药储备预警、物资储备预警、油料储备预警等；所述数据工具层包括数据开发工具、数据资产管理工具、标签工具和智能平台；所述数据开发工具包括离线采集、实时采集、数据处理和作业调度等工具；所述数据资产管理工具包括数据源管理、主题域管理、标签模型管理、算法模型管理、数据资产全景管理和数据溯源管理等工具；所述标签平台包括标签计算引擎(标签服务)和标签配置管理门户，用于生成事实标签、模型标签或算法标签；所述智能平台包括深度学习、强化学习和知识图谱等平台。

所述数据仓储层用于存储部队数据、装备数据、弹药数据、物资数据、油料数据、目标数据、人员数据等。

下面对本发明提供的任务规划中台进行描述，下文描述的任务规划中台与上文描述的任务规划中台设计方法可相互对应参照。

如图2所示，本发明实施例提供一种任务规划中台，所述任务规划中台是基于上述各个实施例提供的任务规划中台设计方法得到的。

可选地，所述任务规划中台包括：

应用平面、控制平面和执行平面，应用平面、控制平面和执行平面是根据软件定义的平面划分方法划分获得的；所述应用平面用于为多种前台应用提供接口和管理所述前台应用；所述执行平面包括业务中台和数据中台，所述业务中台包括多个业务能力中心，所述数据中台包括多个数据能力中心，每个所述业务能力中心用于提供各自对应的业务服务，每个所述数据能力中心用于提供各自对应的数据服务；所述控制平面用于对所述业务能力中心和所述数据能力中心进行注册，所述控制平面还用于基于接入的前台应用对所述业务能力中心和所述数据能力中心进行编排和组装。对于应用平面、控制平面和执行平面的介绍和功能参考上文的介绍，此处不再赘述。

图11示例了一种电子设备的实体结构示意图，如图11所示，该电子设备可以包括：处理器(processor)1110、通信接口(Communications Interface)1120、存储器(memory)1130和通信总线1140，其中，处理器1110，通信接口1120，存储器1130通过通信总线1140完成相互间的通信。处理器1110可以调用存储器1130中的逻辑指令，以执行基于软件定义的任务规划中台架构设计方法，该方法包括：根据软件定义的平面划分方法，将所述任务规划中台分为应用平面、控制平面和执行平面，所述执行平面包括业务中台和数据中台；设计所述业务中台和所述数据中台的层次结构，以及将所述业务中台划分为多个业务能力中心，将所述数据中台划分为多个数据能力中心，每个所述业务能力中心用于提供各自对应的业务服务，每个所述数据能力中心用于提供各自对应的数据服务；基于领域驱动设计方法设计业务能力中心的领域模型以及数据能力中心的领域模型；其中，所述应用平面用于为前台应用提供接口和管理所述前台应用；所述控制平面用于对所述业务能力中心和所述数据能力中心进行注册，所述控制平面还用于根据接入的前台应用对所述业务能力中心和所述数据能力中心进行编排和组装。

此外，上述的存储器1130中的逻辑指令可以通过软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

另一方面，本发明还提供一种计算机程序产品，所述计算机程序产品包括计算机程序，计算机程序可存储在非暂态计算机可读存储介质上，所述计算机程序被处理器执行时，计算机能够执行上述各方法所提供的基于软件定义的任务规划中台架构设计方法，该方法包括：根据软件定义的平面划分方法，将所述任务规划中台分为应用平面、控制平面和执行平面，所述执行平面包括业务中台和数据中台；设计所述业务中台和所述数据中台的层次结构，以及将所述业务中台划分为多个业务能力中心，将所述数据中台划分为多个数据能力中心，每个所述业务能力中心用于提供各自对应的业务服务，每个所述数据能力中心用于提供各自对应的数据服务；基于领域驱动设计方法设计业务能力中心的领域模型以及数据能力中心的领域模型；其中，所述应用平面用于为前台应用提供接口和管理所述前台应用；所述控制平面用于对所述业务能力中心和所述数据能力中心进行注册，所述控制平面还用于根据接入的前台应用对所述业务能力中心和所述数据能力中心进行编排和组装。

又一方面，本发明还提供一种非暂态计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现以执行上述各方法提供的基于软件定义的任务规划中台架构设计方法，该方法包括：根据软件定义的平面划分方法，将所述任务规划中台分为应用平面、控制平面和执行平面，所述执行平面包括业务中台和数据中台；设计所述业务中台和所述数据中台的层次结构，以及将所述业务中台划分为多个业务能力中心，将所述数据中台划分为多个数据能力中心，每个所述业务能力中心用于提供各自对应的业务服务，每个所述数据能力中心用于提供各自对应的数据服务；基于领域驱动设计方法设计业务能力中心的领域模型以及数据能力中心的领域模型；其中，所述应用平面用于为前台应用提供接口和管理所述前台应用；所述控制平面用于对所述业务能力中心和所述数据能力中心进行注册，所述控制平面还用于根据接入的前台应用对所述业务能力中心和所述数据能力中心进行编排和组装。

以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (10)

1.一种基于软件定义的任务规划中台架构设计方法，其特征在于，包括：

根据软件定义的平面划分方法，将所述任务规划中台分为应用平面、控制平面和执行平面，所述执行平面包括业务中台和数据中台；

设计所述业务中台和所述数据中台的层次结构，以及将所述业务中台划分为多个业务能力中心，将所述数据中台划分为多个数据能力中心，每个所述业务能力中心用于提供各自对应的业务服务，每个所述数据能力中心用于提供各自对应的数据服务；

基于领域驱动设计方法设计业务能力中心的领域模型以及数据能力中心的领域模型；

其中，所述应用平面用于为前台应用提供接口和管理所述前台应用；

所述控制平面用于对所述业务能力中心和所述数据能力中心进行注册，所述控制平面还用于根据接入的前台应用对所述业务能力中心和所述数据能力中心进行编排和组装。

2.根据权利要求1所述的基于软件定义的任务规划中台架构设计方法，其特征在于，所述将所述业务中台划分为多个业务能力中心包括：

根据业务领域，对所述业务中台的能力进行划分，得到所述业务能力中心。

3.根据权利要求1或2所述的基于软件定义的任务规划中台架构设计方法，其特征在于，所述设计所述业务中台的层次结构包括：

根据每个所述业务能力中心对应的业务层级或业务对象，将所述业务中台划分为如下业务层：业务实体层、业务协作层和业务活动层，每个业务层包含多个业务能力中心；

所述业务实体层，用于对静态业务实体进行管理；

所述业务协作层，用于对协作业务进行管理；

所述业务活动层，用于对核心业务进行管理；

其中，所述静态业务实体、所述协作业务和所述核心业务是预先定义的。

4.根据权利要求1或2所述的基于软件定义的任务规划中台架构设计方法，其特征在于，所述基于领域驱动设计方法设计业务能力中心的领域模型包括：

对各个所述业务能力中心对应的业务领域进行划分，获得各个所述业务能力中心包含的业务子域；

根据所述业务子域确定各个所述业务能力中心的界限上下文；

基于所述界限上下文，构建各个所述业务能力中心对应的领域模型。

5.根据权利要求1所述的基于软件定义的任务规划中台架构设计方法，其特征在于，所述数据中台的层次结构包括数据资产层、数据工具层和数据仓储层；

所述数据仓储层用于存储数据资源；

所述数据工具层用于为所述数据资产层提供数据处理工具、标签以及管理所述数据资产层产生的数据资产；

所述数据资产层用于获得数据资产以及确定数据资产对应的标签。

6.根据权利要求5所述的基于软件定义的任务规划中台架构设计方法，其特征在于，所述数据资产层包括数据源模型、主题域模型、标签模型和算法模型；

所述数据源模型用于获取数据资源；

所述主题域模型用于对所述数据资源进行筛选和加工从而形成数据资产；

所述标签模型用于确定数据资产对应的标签；

所述算法模型用于提供计算功能，所述计算功能至少包括以下一种：计算预警数据、计算推荐数据或数据统计。

7.根据权利要求5所述的基于软件定义的任务规划中台架构设计方法，其特征在于，所述数据工具层包括数据开发工具、数据资产管理工具、标签工具和智能平台；

所述数据开发工具用于采集原始数据；

所述数据开发工具还用于对所述原始数据进行处理，获得数据资源；

所述数据资产管理工具用于对数据资产进行管理；

所述标签工具用于基于标签配置规则生成标签；

所述智能平台用于提供智能计算工具。

8.一种任务规划中台，其特征在于，基于如权利要求1-7中任一项所述的基于软件定义的任务规划中台架构设计方法设计得到。

9.一种电子设备，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现如权利要求1至7任一项所述基于软件定义的任务规划中台架构设计方法。

10.一种非暂态计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至7任一项所述基于软件定义的任务规划中台架构设计方法。

Images