低空无人设备接入与调度平台｜无人机、无人车、无人船

客户是谁

某市级低空经济与无人系统项目。

遇到什么问题

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

该场景也不是从零开始，而是系统不少、口径不一：

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

我们做了什么

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

• 先做统一身份与计划，再做态势大屏。态势画面最直观，但它依赖可信的对象身份和一致的计划状态；不知道这是谁的设备、有没有对应的任务，画面再丰富也只是把混乱可视化。方案先落身份档案、登记审核与计划状态，把可追溯的链条立住，再向上叠加监测与告警。
• 监管侧与服务侧分开建模。前者关注计划状态、异常识别与处置留痕，强调规则稳定、操作可追溯；后者关注申请、查询、消息与统计，强调易用和多端覆盖。两者共用身份与计划数据，但权限模型、页面节奏和变更频率完全不同。
• 让边缘节点具备自治能力。实时性发生在现场，链路抖动时中心不应成为唯一依赖：现场节点承担设备接入、缓存与本地规则判断，中心侧负责跨域汇聚、统一规则与长期留存；断链期间现场继续监测并保留记录，恢复后补齐。
• 不推倒重来。既有监管与业务系统通过标准接口接入，平台承担的是身份、计划与运行数据的统一口径，以及跨系统的状态对齐；不同厂商的数据格式与指令差异封装在接入层，不向业务层扩散。与飞行服务、气象情报等外部能力的关系是引用而非替代，原始服务的提供方式不变。

难点怎么解决的

• 多源态势怎么对齐：地图、气象、轨迹、视频与告警按统一的时空口径进入态势空间，来源与更新频率的差异在接入层吸收。
• 链路不稳时不能停摆：云边分工——现场节点接入、缓存并在本地判断规则，中心侧汇聚与留存；断链期间现场继续监测并留记录，恢复后补齐。
• 新增一类载体不能重做底座：扩展接入适配与业务规则即可，身份与计划底座不动。

交付了什么

交付物是建设方案与平台框架设计。平台按分层方式组织：多端访问与统一接入控制身份和服务流量，业务层承载身份管理、计划管理、运行监管与运行服务，数据层处理时空数据、实时计算、轨迹分析与规则告警，云边基础设施支撑中心与现场节点的弹性运行。运行主链路是一条可追溯的序列——身份与设备登记、任务计划提交、审核与计划协同、运行态势监测、告警与处置跟踪、任务归档与复盘，每个环节都有明确的责任角色，申请用户、运营人员、设备管理人员、值守人员、处置人员与管理人员在同一套状态定义下接力；异常按围栏侵入、偏航、动力与通信几类做分级提示、定位和处置跟踪。落地顺序建议分四个阶段：先做现状与接口梳理，把角色、数据口径和边界固定下来；再建身份与计划底座；然后叠加运行监测与告警；最后开放多端服务入口，按实际使用反馈扩展载体类型与部门入口——每一阶段都有可确认的产出。

交付范围到方案与平台能力边界为止：空域事项、飞行活动审批与相关政策制定由主管部门按现行规定办理，平台仅承载流程与信息流转；硬件整机与传感器的采购、改装及线下运维由设备方承担，平台承载接入与运行信息，不替代设备自身管理；既有行业监管系统与飞行服务站等外部系统以标准接口对接与数据引用为主，不做替换；云网环境部署与安全合规测评的实施及相应责任由具备相应资质的主体另行承担；与实际飞行安全直接相关的责任边界不由平台承担或改变。

现在的状态

本案例公开的是方案设计与平台能力边界这一段的范围与做法。方案中的规模与处理能力属于设计目标，尚未形成第三方测试结论；具体区域、网络拓扑、节点数量与部署等级等细节不在公开版本中，实际运行规模与验收结果以正式建设与验收文件为准。