1. 课程导入
无人机远程识别（Remote ID，简称 RID）可以理解为无人机在飞行过程中向外界持续广播的一张“电子车牌”。它并不依赖飞手主动上报，而是由无人机系统按照既定格式、既定频率、既定内容，把身份、位置、高度、速度、起飞点、控制站位置等关键信息发送出去，使监管方、其他空域用户和公众接收设备能够识别“谁在飞、飞在哪里、什么时候飞”。从工程视角看，Remote ID 不是单一功能，而是一条由机载数据源、广播/网络链路、消息编码、接收解析、合规判定共同构成的信号链。
本课程围绕“合规测试工程”展开，目标不是只讲法规条文，而是把法规要求转化为可测试、可复现、可追溯的工程活动。也就是说，我们要回答三个问题：第一，Remote ID 到底要求发送什么；第二，如何用测试手段证明它确实发送了、发送正确、发送稳定；第三，当测试失败时，如何定位是数据源、编码、射频、时间同步还是接收端解析的问题。
1.1 核心原理：Remote ID 的信号链与合规边界
Remote ID 的典型工作方式分为广播式与网络式两类。广播式通常基于蓝牙 4/5 或 Wi-Fi Neighbor Awareness Networking（NAN）等无线技术，以短报文形式周期性发送；网络式则通过蜂窝网络或互联网把消息上传到远程识别服务提供方。无论哪种方式，其核心数据项都包括：无人机唯一标识、无人机型号/序列号、起飞位置、当前经纬度、高度、速度、航向、时间戳、控制站位置、紧急状态等。测试工程要做的，是把这些“字段级要求”映射为“可观测的测试点”。
上图把 Remote ID 拆成“数据源—编码—广播—接收解析”四段，并在下方标出 T1 至 T4 四类测试点。这样做的意义在于：合规测试不是只测“能不能收到”，而是逐段验证信号链的完整性。任何一段失效，最终都会表现为接收端看不到、看不全或看不准。
1.2 合规测试工程的意义：从“功能可用”到“证据可审计”
很多团队第一次接触 Remote ID 时，容易把它当成一个“能广播就行”的功能。但在监管与认证场景中，真正被关注的是可审计性：测试是否覆盖了全部必填字段，测试条件是否可复现，失败样本是否保留，时间同步是否可追溯。合规测试工程的价值，正是把“我觉得没问题”变成“我有证据证明它符合要求”。
具体来说，它带来四方面收益：第一，降低认证风险，提前发现字段缺失、单位错误、广播间隔超限等问题；第二，缩短排障时间，因为测试点已经分段，失败时能快速定位到数据源、编码还是射频；第三，支撑多机型复用，测试用例和判定规则可以沉淀为工程资产；第四，满足监管留痕要求，测试日志、抓包文件和判定结果可以形成完整证据链。
核心认知：Remote ID 合规测试的对象不是“无人机能不能飞”，而是“无人机在飞行中是否按规定的格式、频率和内容持续对外声明自身身份与状态”。测试工程要把法规语言翻译成可执行的测试步骤和判定阈值。
1.3 方法流程：一条可复用的合规测试主线
为了让后续章节有统一的方法论，本课程采用如下测试主线。它既适用于广播式 Remote ID，也可以扩展到网络式 Remote ID 的测试场景。
- 需求拆解：把法规和标准中的必填字段、更新频率、精度要求、时间要求逐条列出，形成检查表。
- 测试设计：为每个检查项设计测试点、测试环境、输入条件和判定阈值。
- 环境搭建：准备无人机、接收机、频谱仪、屏蔽箱或外场，确保时间同步和坐标基准一致。
- 执行与采集：按用例执行飞行或静态广播，采集原始报文、接收日志、频谱数据和视频记录。
- 判定与复测：对照阈值给出通过/失败结论，失败项进入根因分析并复测。
- 证据归档：把用例、数据、结论、版本信息打包，形成可审计的测试报告。
下面给出一个简化的测试配置片段，用于说明测试环境中的关键参数如何记录。实际项目中，这些参数应写入测试用例和报告模板。
# Remote ID 合规测试配置示例（片段）
test_case: RID-BROADCAST-001
dut: UAV-X4 / firmware 2.3.1
transport: BLE 4.2 / Wi-Fi NAN
broadcast_interval_ms: 1000
required_fields:
- uas_id
- takeoff_lat_lon
- current_lat_lon
- altitude_geodetic
- speed_horizontal
- timestamp
- operator_lat_lon
receiver: RID-RX-02 / firmware 1.8.0
environment: outdoor_open_field
time_sync: GPS PPS + NTP fallback
pass_criteria:
field_completeness: 100%
interval_jitter_ms: <= 200
end_to_end_latency_ms: <= 1500
1.4 案例与场景：一次典型的“收不到”排障
某次外场测试中，接收机在 50 米内可以收到 Remote ID，但超过 120 米后频繁丢失。初步怀疑是发射功率不足，但频谱仪显示功率正常。进一步检查发现，广播间隔在无人机机动时出现明显抖动，部分报文间隔超过 2 秒，导致接收端在移动场景下错过消息。根因是飞控在姿态解算繁忙时，Remote ID 任务被低优先级调度，编码打包被延迟。修复方式是把 Remote ID 广播任务提升为独立周期任务，并增加发送时间戳的单调性检查。复测后，120 米处接收成功率从 62% 提升到 99% 以上。
这个案例说明：合规测试不能只看“静态能不能收到”，还要覆盖机动、遮挡、远距离和电磁干扰等场景。测试工程要把“场景变量”显式纳入用例设计，否则很容易在认证或实际监管场景中暴露问题。
1.5 常见误区与复盘要点
| 误区 | 表现 | 纠正方式 |
|---|---|---|
| 只测“能收到” | 接收端能看到目标，但字段缺失或单位错误 | 按字段级检查表逐项验证，保留原始报文 |
| 忽略时间同步 | 时间戳漂移，无法判断消息新鲜度 | 使用 GPS PPS 或 NTP 校准，记录时间偏差 |
| 只做静态测试 | 机动时广播间隔抖动、丢包率上升 | 增加机动、遮挡、远距离和干扰场景 |
| 证据链不完整 | 失败后无法复现，无法定位责任环节 | 用例、日志、抓包、版本、环境一并归档 |
学习建议：在学习后续章节时，始终带着“这个知识点对应哪个测试点、用什么数据判定、失败时如何定位”三个问题。这样能把法规、协议、射频和测试工具串成一条完整的工程主线。
1.6 学习目标与整体课程框架
完成本课程后，学习者应能够：理解 Remote ID 的基本概念与法规背景；掌握广播式与网络式 Remote ID 的消息结构和关键字段；能够设计合规测试用例并搭建测试环境；能够使用接收机、频谱仪和抓包工具采集与分析数据；能够对常见失败模式进行根因定位；能够输出可审计的测试报告。