空域 / 知识与设计
UTM | 协同共享空域的结构
单靠一张地图或一家公司是做不到的。我们拆解运营者、服务提供商和主管机构之间需要彼此共享的内容。
按顺序阅读本页
01
UTM 涵盖什么
FAA 将 UTM（UAS 交通管理）描述为一个协同管理低空无人机运行的生态系统。它是对现有空中交通服务的补充概念，涵盖规划、空域授权、监控、冲突管理等。这并不意味着全球有一套已经完成并投入使用的单一系统。
来源：FAA | UAS Traffic Management02
梳理每个参与方的职责
| 参与方 | 角色 | 设计必须回答的问题 |
|---|---|---|
| 运营者 | 目的、规划与现场判断 | 谁对这次运行负责？ |
| 运行支持服务 | 整理计划与约束，交换信息 | 提供哪些信息，质量如何？ |
| 其他服务 | 与相邻运行的协调 | 共享什么，如何更新？ |
| 主管机构及类似组织 | 规则、约束与授权的框架 | 法律权限与应用权限有何不同？ |
| 数据提供方 | 天气、地形等补充信息 | 新鲜度、精度和使用条款如何？ |
上表是以 FAA 的概念为起点所做的设计层面拆解。角色会随各国规则和各份合同而变化，因此实施时请具体界定责任边界。
03
把意图、观测与授权分开保存
FAA 的 UTM 演示处理的是运行意图与空域活动信息的交换。从这一点出发思考 Airffic World，自然就会把三样东西分开保存：计划了什么、实际观测到什么，以及主管机构批准的条件。
来源：FAA | UTM Pilot Program| 数据 | 示例 | 含义 |
|---|---|---|
| 意图 | 我想在这个时间窗内使用这块空域 | 计划或请求 |
| 观测 | 在这个时刻观测到了这个位置 | 测得或接收到的信息 |
| 授权 | 在特定条件下获得授权的记录 | 法律或程序依据 |
| 评估 | 这一版输入存在潜在冲突 | 计算或检查的结果 |
04
一个最小系统的提案
不要一开始就试图管理全国每一架飞机。先从给自己的计划做版本管理、获取约束数据、保留每个决定背后的依据做起。只有在可用的 API、合同和运行安排都齐备的地方，才接入外部服务。
| 组件 | 职责 |
|---|---|
| 规划服务 | 运行意图的版本管理 |
| 约束服务 | 标注了来源与有效期的信息 |
| 评估服务 | 附带理由的检查结果 |
| 审计日志 | 谁确认了什么的记录 |
| 外部连接器 | 面向各主管机构、对等服务、天气提供方等的认证、重试与故障约定 |
这一结构是一份提案。本站并不作为 UTM 或授权服务运行。
完成的定义
上线之前，请检查以下各项。
- 计划、观测与授权数据绝不混淆。
- 外部信息的时间戳与来源可以核查。
- 服务之间的责任边界，以及故障时联系谁，均已确定。
用于规格评审与验收测试的设计检查项。
查看资料来源
有关规则与定义的解说参考了以下资料。界面、数据模型与完成的定义均为我们自己的设计提案。
- FAA | UAS Traffic ManagementUTM 概念与协同交通管理
- FAA | UTM Pilot Program包括运行意图与空域信息交换在内的演示
资料核对日期：2026 年 9 月 30 日。针对您的具体情况，请以最新的官方信息为准。