全空间无人体系运行管理平台

项目背景

低空经济进入城市运行，最先出现的不是设备不够，而是秩序不够。同一座城市里，无人机承担巡线、巡查与配送，无人车承担地面接驳与巡检，无人船承担水域巡查，三类载体的运营主体、监管口径和数据格式各不相同。一个跨越地面与水面的任务，往往要在多套系统、多个部门之间反复对接。单设备、单厂商的管理方式难以支撑跨空间、跨部门、多终端的协同，这个场景缺的不是又一套监控软件，而是一套统一的数字化运行底座。

我们在其中承担的是面向该场景的建设方案与平台框架设计：把身份、计划、监管与服务这几层的关系理清，界定平台做什么、不做什么，以及按什么顺序落地。

场景当时的状态

该场景面对的不是从零开始，而是系统不少、口径不一。设备与人员档案分散在厂商平台、企业台账和业务系统里，缺少统一的登记口径；任务申报、计划处理、实时监管与服务入口分属不同系统，同一条任务的状态在几处对不上；态势空间要叠加地图、气象、轨迹、视频与告警等多源数据，来源和更新频率各不相同；使用方包括政府主管部门、运营企业、一线运营人员与公众，需要的界面和权限差别很大。还有一条现实约束：现场网络与中心链路并非始终稳定，监测与指令不能只依赖中心侧。

我们的做法与取舍

第一个取舍是先做统一身份与计划，而不是一上来做三维大屏。态势画面最直观，但它依赖可信的对象身份和一致的计划状态；不知道这是谁的设备、有没有对应的任务，画面再丰富也只是把混乱可视化。方案先落身份档案、登记审核与计划状态，把可追溯的链条立住，再向上叠加监测与告警。

第二个取舍是监管侧与服务侧分开建模。前者关注计划状态、异常识别与处置留痕，强调规则稳定和操作可追溯；后者关注申请、查询、消息与统计，强调易用和多端覆盖。两者共用身份与计划数据，但权限模型、页面节奏和变更频率完全不同，混在一起做往往两边都做不好。平台承载的是流程与信息流转，具体空域与飞行事项仍由主管部门按现行规定办理，我们不对行政效力作任何预设。

第三个取舍是让边缘节点具备自治能力。实时性发生在现场，链路抖动时中心不应成为唯一依赖。方案在云与边之间划分职责：现场节点承担设备接入、缓存与本地规则判断，中心侧负责跨域汇聚、统一规则与长期留存；断链时现场仍可继续监测并保留记录，链路恢复后补齐。

平台如何承载运行秩序

平台按分层方式组织：多端访问与统一接入控制身份和服务流量，业务层承载身份管理、计划管理、运行监管与运行服务，数据层处理时空数据、实时计算、轨迹分析与规则告警，云边基础设施支撑中心与现场节点的弹性运行。运行主链路是一条可追溯的序列：身份与设备登记、任务计划提交、审核与计划协同、运行态势监测、告警与处置跟踪、任务归档与复盘。每个环节都有明确的责任角色，申请用户、运营人员、设备管理人员、值守人员、处置人员与管理人员在同一套状态定义下接力；异常按围栏侵入、偏航、动力与通信几类做分级提示、定位和处置跟踪。

与既有系统和其他能力的关系

方案不主张推倒重来。既有监管与业务系统通过标准接口接入，平台承担的是身份、计划与运行数据的统一口径，以及跨系统的状态对齐；不同厂商的数据格式与指令差异封装在接入层，不向业务层扩散。与飞行服务、气象情报等外部能力的关系是引用而非替代：平台把这些信息放进任务与态势的上下文，原始服务的提供方式不变。扩展方式上，新增一类无人载体或新增一个部门入口，理想情况下只需扩展接入适配与业务规则，不改动身份与计划底座。

分阶段落地建议

我们建议按四个阶段推进：先做现状与接口梳理，把角色、数据口径和边界固定下来；再建身份与计划底座，形成可追溯的登记与状态链；然后叠加运行监测与告警，让值守和处置有统一视图；最后开放多端服务入口，按实际使用反馈扩展载体类型与部门入口。这个顺序的考虑，是让每一阶段都有可确认的产出，后续投入依据前一阶段的实际使用情况再定。需要说明的是，本稿公开的是方案设计与平台能力边界，方案中的规模与处理能力属于设计目标，尚未形成第三方测试结论，实际运行规模与验收结果以正式建设与验收文件为准。