之前给大家介绍了体系本体的一项研究。

体系本体的核心概念：体系（SoS）、利益相关者、环境、组成系统、资源、能力、星座、能力配置、体系作战概念、体系任务、任务线程、体系能力。

在这个体系本体中，虽然也涉及到了体系要完成的任务（Mission，也可以称之为使命任务或使命），但是没有展开研究任务本体应该如何设计。

因此，本文给大家介绍一项关于任务本体设计的研究（详见本文参考资料[1]）。

这项研究的关键洞察是，在不同领域（比如体系工程、ISR 情报监视侦查、网络安全、任务工程等）其实已经有关于任务的本体或概念体系，但是 缺乏一个能够跨学科的统一、通用的任务本体 。这种跨学科的语义模糊性，成为了制约复杂体系集成与互操作性的重要瓶颈。

该研究直面这一挑战，系统收集整理和分析了不同领域的任务本体，然后在此基础之上，构建了一个名为 统一任务本体 的高阶知识框架。其研究手法有点类似德国哲学家本雅明的“星座”方法，即先收集知识碎片，然后构建知识星座。

统一任务本体

设计统一任务本体的目的，并非是要取代任何特定领域的任务本体，而是要充当一个更高阶的中间层级的本体，将不同领域对任务统一理解，映射到一套共享的核心概念和关系上，从而实现真正的跨领域的任务语义互操作。 这项研究在最后，还基于这个统一任务本体，结合国防部任务工程指南中的任务概念结构（见下图），设计了一个任务工程的任务本体（见本文第五部分）。

国防部任务工程视角下的任务概念结构。基于这个任务工程的概念结构和统一任务本体，就可以设计出任务工程领域的任务本体。

• 任务工程
• 体系工程
• 本体工程
• 集成与互操作
• 数字工程
• 试验鉴定

一、为何需要一个统一任务本体？

任务工程作为一门新兴学科，近年来在美国国防部的推动下迅速发展。

任务工程可以帮助国防部看清任务结果如何受各种变化影响。它系统评估多个关键因素：体系、系统、威胁态势、作战概念、任务环境和任务架构。从而让决策者预判任何调整带来的影响。

国防部发布的任务工程指南v1.0和v2.0两个版本

在任务工程指南v2.0版本中，建议的任务工程的科学分析流程

任务工程关注的是如何从顶层的任务目标出发，指导系统、体系的设计、集成与试验鉴定和运行保障，确保最终交付的能力能够有效支撑任务的成功。下图为任务工程的概念模型。

根据上图的任务分析流程，得到的任务工程的概念模型

在国防部任务工程指南中，任务 指系统或体系所要支持的军事作战需求或作战任务。这个定义更强调作战能力交付以支撑作战使命任务，而非单次作战行动。

除了任务工程这个领域，任务这个重要概念在其他重要军事领域也被广泛使用，但其含义和任务工程中其实是有一定的差异。

比如，美国太空军的任务，是指 组织、训练和装备太空部队，以保障美国及其盟友在太空的行动自由，并保护美国在太空的利益。

这一定义强调三点核心：行动自由，确保美军能不受干扰地使用太空；全域支撑，太空能力服务于陆、海、空、网、天等所有作战域；利益保护，不仅保护军事太空资产，也涵盖商业、民用等国家太空利益。

太空军采用 “Mission Delta” 组织模式，以任务类型划分作战单位。这也就意味着，每个 Delta 作战单位的任务的定义，和太空军总体的任务定义又有不同。

美国太空军的不同的任务Delta部队，其各自的使命任务又有不同。

无人机 ISR 任务，指一次具体的无人机执行的情报、监视或侦察行动，目的是为指挥决策提供实时或近实时信息支持。其最关注的是情报产出、任务剖面、人机协同、时效性与生存性。陆军的空射效应（ALE）小型无人机和空军的高空长航时大型无人机的 ISR 任务，也会有不同的定义。

在美国网络司令部的网络安全语境下，任务通常指组织（尤其是军事或关键基础设施单位）的核心业务职能或作战职能。网络安全的目标是 以任务为中心 保障任务在网络威胁下仍能持续、可靠运行。其最关注持续运行能力、网络-物理-任务耦合。网络司令部下辖的不同单位的任务，又可以分为网络进攻、网络防御、信息战等任务。

美国网络部队的不同单位，其任务又不同。

从上面这几个例子，我们不难看出，每个领域及其细分领域，由于其业务特殊性，都会发展出自己的一套任务相关的概念。这种多样性虽然满足了特定领域的精细化需求，却在跨域任务协作时，制造了巨大的语义壁垒。

语义壁垒既阻碍了利益相关者之间的有效沟通，也限制了任务在不同领域之间的互操作性。尤其在需要多系统协同的复杂场景（如多域战）中，缺乏共享语义基础会使信息集成困难、互操作性差。

为此，需要构建一个跨领域的统一任务本体。

二、不同领域任务概念的共性与差异

2.1 不同领域的任务本体

为了构建一个真正具有普适性和包容性的统一任务本体，研究团队首先系统梳理了不同领域的任务本体。

这一步骤是整个研究的基石，其目的是全面、客观地分析现有的不同领域的任务本体。

下表为不同领域的任务本体的清单。

2.2 对不同领域的任务本体综合分析，得到的关键发现

通过对这些不同领域的任务本体进行深入分析，研究团队有了三个关键发现。

首先， 在所有任务本体中，与任务概念共同出现频率最高的三个核心概念是“具体任务”（Task）、“行动”（Operation）和“活动”（Activity）。这表明，无论领域如何，将高层级的任务逐层分解为更具体的、可执行的工作单元，是一种普遍的建模模式。

其次， 不同领域的任务本体在设计好后，对任务本体的适用性进行验证和确认（V&V）时，主要依赖领域专家评审和场景分析。这反映了任务本体的正确性，高度依赖于其是否符合特定领域的实际业务逻辑。

最后， 也是最重要的一点，尽管各领域使用的具体术语不尽相同，但其背后所试图捕捉的抽象概念却存在很大的相似性。

这三个发现，为统一任务本体的构建，提供了宝贵的实证依据。它证明了跨域任务概念统一的可能性，并指明了哪些概念是构建这一统一框架的 公分母 。

三、统一任务本体

这项研究通过三个本体设计步骤（详见本文第四部分），最终设计出了统一任务本体（下图）。

以UML类图的形式呈现的 统一任务本体 ，清晰地展示了任务相关的核心概念之间的逻辑关系。

统一任务本体一共 包含15个核心概念 （下表）。这些概念 分为结构概念和行为概念两大类。结构概念如任务、目标、系统相对稳定，描述任务是什么；行为概念如行动、具体任务、条件、测量则随时间变化，描述任务如何执行。

下表中的第三列，是各个概念的元信息。它本质上是任务本体中每个概念的 设计约束与使用语境 ，避免跨领域应用这些概念时出现语义漂移。

四、统一任务本体构建方法

在系统梳理了不同领域的任务本体之后，研究者通过三个步骤，从纷繁复杂的多个领域的任务本体中，归纳提炼出最本质、最通用的任务概念和关系。

第一个步骤是提取跨领域的核心共性概念，构建最小任务本体。

研究团队发现，超过半数的主要研究都直接或间接地参考了美国国防部的相关框架和术语表，如国防部体系架构框架（DoDAF）、任务与手段框架（MMF）以及国防部任务工程指南。

图左：MMF任务与手段框架。图右：MMF 本体

研究团队于是从这些权威的概念框架中，提取了最核心、最通用的概念和概念之间的关系：任务拥有目标、整合行动、分解为具体任务；行动包含具体任务；具体任务具有意图、描述行为、分配给角色。

这些最核心和最通用的概念和关系，就构成了统一任务本体的最小任务本体。

第一步：构建最小的任务本体。基于美国国防部不同框架与术语表，提取的核心任务概念和关系的UML类图。图中 Mission（任务） 类居中枢地位，通过不同关系连接周边概念。这几个核心直接源于DoDAF、MMF等权威框架，其核心价值在于提供跨领域的任务本体的最小公倍数。

第二个步骤是选择性融合纳入各领域的特有概念。

确定了最小任务本体之后，研究团队仔细分析了不同领域的任务本体，各自有哪些特有的概念。 然后分析这些领域特有的概念，是否有必要融合到这个最小任务本体中。

例如，网络安全的任务本体，会强调任务的“时间边界”和所需“能力”等概念；而无人机情报、监视与侦察（ISR）的任务本体，则有“空间上下文”和“授权实体”等概念。

这些概念，其实是特定于不同任务领域的，因此不能不管三七二十一，把它们都一股脑儿全塞进统一任务本体。

这些特定领域的概念，可以被吸收纳入统一任务本体。但需要通过本体设计师的面试。面试会遵循严格的本体设计规则：新纳入的概念，必须提供新的有用视角，且无法被已有概念覆盖。

通过这种方式，统一任务本体既巧妙地融合了来自不同领域的精华概念，同时保持了自身的简洁性。

例如，ISR 任务领域的 平台 概念，就面试成功，被纳入到统一任务本体之中。这是因为不管是 ISR 任务，还是其他领域的任务，都需要部署到具体的平台载体上。但是，负责分配 ISR 任务的 权威实体 概念，则面试失败吃了闭门羹，被统一任务本体拒之门外。这是因为权威实体这个概念，只是任务执行者的一种角色，它可以用最小任务本体中已有的更抽象的 角色 概念来涵盖。

这种宁缺毋滥的保守面试策略， 体现本体构建的奥卡姆剃刀原则。其目的是 确保 统一任务本体 不会太过臃肿，变成无所不包的概念大杂烩。

第二步（a）：将不同领域本体的重要概念，融入到最小任务本体内（红色为新增部分）。该UML类图在最小任务本体基础上，从 ISR 任务领域和网络安全领域的任务本体中，纳入了 Platform（平台） 、 Capability（能力）、 Time（时间） 类与 Resource（资源） 类。增加了这几个概念之后，统一任务本体从战略框架下沉到战术资源配置层面，不仅要说清任务（Mission）是什么（包括目标、行动和具体任务），还必须明确执行具体任务的角色需要哪些作战能力（Capability）和哪些作战资源（Resource），具体任务在什么时候完成（Time），执行具体任务需要哪些具体的平台（Platform）。

第二步（b）：继续将不同领域本体的重要概念，纳入到最小任务本体内（黄色为新增部分）。 该UML类图进一步整合 MMF任务与手段框架 与 体系工程任务本体，在上图基础上，新增 Condition（条件） 类和 constrains（约束） 任务约束关系，以及 System（系统） 类及其子类 Constituent System（组成系统） 与 System of Systems（体系） 。

在统一任务本体中，任务、具体任务、平台、角色、组成系统 、 能力、资源之间的关系的示例 ：Mission（监视敌方舰队）→ 任务分析为Task（广域海上监视具体任务）→ Task （广域海上监视具体任务） 分配 Role（反潜机角色） → Task（广域海上监视具体任务） 部署到 Platform（特定P-8A反潜机平台） → Role（反潜机角色）指定 Capability（广域海上监视）→ Role（反潜机角色） 指定到组成系统（P-8A反潜机组成系统）→ Role（反潜机角色）使用 Resource（反潜导弹、声呐浮标）。

第二步（c）： 作为最终版的统一任务本体的UML类图，该图整合前面三个版本，并融入 Stakeholder（利益相关方） 、Environment（环境）、Measurement（测量）、 Constellation（星座） 这四个概念，形成军事任务的通用语义本体。

上图中的 Measurement（测量）、Environment（环境）、Stakeholder（利益相关者）、Constellation（星座） 这四个新纳入的概念，都来源于体系工程的任务本体。

• Measurement（测量）： 通过任务测量将任务与 MoE/MoS 等作战评估指标显性关联，用来告知利益相关者系统和体系对任务目标的支撑度。
• Environment（环境）： 系统在任务环境中行动，任务环境通过 influences（影响） 关系与任务互动。任务环境不再是静态背景板，而是主动影响任务执行的动态约束条件。
• Stakeholder（利益相关者）： 用于明确用于完成任务的系统的所有者 。
• Constellation（星座/协同群组）： 星座 通过 realizes（实现）关系与能力关联，用于刻画现代分布式体系作战（如无人蜂群、有人无人协同）的系统可组合性以及作战能力服务化的可替代性。

第三步是提炼与抽象。

研究团队基于上述不同领域的任务本体，提出了一个更高维度的分类视角，将统一任务本体中的概念划分为三类：结构概念、行为概念和知识概念。

这种划分源于对任务本质的多维理解，分别对应“任务由什么组成”、“任务如何执行”以及“任务应该如何设计”。

• 结构概念： 描述任务的静态组成部分，如任务（Mission）、目标（Goal）、系统（System）、利益相关者（Stakeholder）等。因此，结果概念定义了任务由什么组成。
• 行为概念： 捕获任务的动态执行过程，如具体任务（Task）、行动（Operation）、条件（Condition）、测量（Measurement）等。因此，行为概念描述了任务如何执行。
• 知识概念： 为每个结构概念或行为概念规定了一套核心属性，用以指导本体设计人员如何在特定领域实例化这个概念。例如，对于目标这一结构概念，其知识概念的描述会包括“具体性、可衡量性、可达成性、相关性和时限性”等属性。因此，知识概念规定了设计实现特定领域的结构概念或行为概念时，本体设计师应该当心和依赖的假设、理由和上下文背景信息。

五、基于国防部任务工程指南的任务本体构建

研究者最后基于统一任务本体，结合《国防部任务工程指南》，设计了任务工程的任务本体。

任务工程指南将任务执行分解为多个相互依赖的部分（下图中不同颜色分类）。

国防部任务工程的概念结构

研究团队从这个概念结构中，提取出四个核心维度：目标、行动、场景和环境，构建出任务工程指南的任务模型（下图）。

国防部任务工程的任务概念模型。 该UML类图将MEG的复杂流程简化为 Goal（目标）-Operation（行动）-Scenario（场景）-Environment（环境） 四个正交的维度，构成任务工程的任务空间。

基于这个任务概念模型，结合前面介绍的统一任务本体，就得到了下图的任务工程指南的任务本体。

任务工程的任务本体UML类图。这个任务工程的任务本体，是在任务工程四维模型基础上，结合统一任务本体设计出来的。