简介RTCA DO-365B-2021是RTCA正式发布的《Detect and Avoid (DAA) Systems 最低运行性能标准MOPS》由SC-228专家委员会编制并于2021年3月批准发布。DAA系统是无人机融入国家空域系统运行的关键技术之一这一标准重点定义了探测、跟踪、告警和避让等功能模块的最低性能要求以及对应的测试与评估方法。资源面向航空电子系统工程师、无人机/有人机融合运行规划人员、适航审定工程师和安全评估人员可用于指导DAA设备研发、系统集成和适航取证。压缩包内包含1个PDF文件大小为18.7MB正文完整、章节清晰便于按需检索。相比2017年初版DO-365B增加了终端区动态无冲突DWC运行、穿越B类空域和地面GBSS支持等修订内容相关更新对实际工程落地尤为重要。目前已有1329人学习下载适合需要系统掌握DO-365B规范的专业技术人群。 上个月整理项目资料时我又翻到那份名为RTCA DO-365B-2021.pdf的文件。收到这份PDF的时候一般不需要附加解释——做无人机整机、地面站或者探测设备的人都知道团队接下来几个月的需求清单基本都得围着“探测与避让Detect and AvoidDAA”这四个字转。DO-365B是RTCA发布的《DAA系统最低运行性能标准MOPS》在2021年的修订版它规定了无人机这套“空中注意力和主动避险系统”必须达到的底线传感器要看到多远的冲突目标、航迹跟踪要稳到什么程度、告警在什么时机响、地面操作员应该收到什么样的引导。凡是打算做超视距运行BVLOS的团队都会在某个节点开始面对这份标准。这篇不打算逐条翻译标准原文而是用我自己做项目、试飞和适航沟通中积累的视角聊聊DO-365B究竟在约束什么、从A版到B版行业在修正什么以及落地时最容易在哪些地方翻车。如果你正打算把这份PDF丢给研发团队或者自己就是那个被丢PDF的人希望这篇能帮你先画出重点。1. 聊DO-365B之前先弄懂DAA在空域里的位置1.1 无人机凭什么安全融入有人机空域有人驾驶飞机之所以能在一个管制空域里安全穿行靠的是“机组人员在驾驶舱里看见并避让”这条基本原则再加上TCAS这类机载防撞系统做最后防线。但无人机的情况完全不同驾驶舱里没有飞行员远程操作员在地面站里既看不到窗外也感知不到飞机的姿态变化和周边态势。尤其到了BVLOS阶段飞机飞出视距之外操作员对周围空中交通的判断几乎全部依赖机载传感器和地面站显示。DAA系统的本质就是把有人机飞行员那套“观察—判断—决策—机动”的闭环用机器重新做一遍。机载传感器负责观察跟踪与威胁评估算法负责判断地面站告警与引导界面负责决策支持最后要么由自动飞行控制执行避让机动要么把避让建议推送给远程操作员。DO-365B就是给这条链路上每个环节定下最低性能及格线。一个比较贴切的类比是有人机像自己开车司机有眼睛还有副驾帮忙看无人机像一个远程代驾车里装了一套自动预警雷达但发号施令的人在几百公里外中间还隔着一条有延迟的数据链路。所以这套系统对预警提前量、告警清晰度、链路断连情况下的表现要求比TCAS苛刻得多。1.2 DO-365B在规则体系里是什么位置RTCA不是政府机构而是由航空工业界、局方、科研单位共同参与的标准组织。DO-365B这种最低运行性能标准本质上是行业共同承认的“可接受的符合性方法”。换句话说当你向局方证明“我的无人机具备DAA能力”时按DO-365B来设计、验证、试飞是当前最主流也最容易沟通的路径之一。要提醒一句DO-365B本身不等于适航批准也不等于运营许可。它解决的是“DAA系统性能是否达标”这个技术判断问题。真正飞上天还需要满足适航规章里关于整机、数据链路、地面站、软件、电磁兼容等方面的要求真正去运营还要满足民航局对运营人、空域、气象、运行程序的批准条件。DO-365B是入场券里最硬的那一张但不是唯一一张。1.3 这份标准到底写给谁我在项目里见过一个现象拿到DO-365B版本的人往往会先把PDF转给软件工程师然后软件工程师看两页就头大了。原因很简单不同角色在这份标准里要关注的东西完全不一样角色最该关注的方向常见误区无人机整机/系统集成DAA系统与飞控、链路的功能接口避让机动执行的边界把DAA当成单独设备不纳入系统架构地面站软件工程师OWS操作员告警、显示符号、告警抑制与交互逻辑只盯界面样式忽略告警率和时延传感器/算法团队探测距离、更新率、航迹融合、威胁评估阈值用实验室指标代替整机环境下的实测指标适航与质量工程师需求追溯、验证方法、符合性材料组织只看结论不看验证边界运营人/飞手DAA对运行场景的限制、告警后的处置程序以为DAA是全自动的完全不用人管我后来带着团队做标准解读时第一步一定是先给每个人画清楚“你只需要吃透哪几章”而不是让大家从头读到尾。2. 从DO-365A到DO-365B到底动了哪几刀2.1 “最低运行性能标准”的潜台词先理解MOPS这三个词里的“性能”二字。它不规定你必须用雷达还是ADS-B接收机不管你的传感器装在机头还是机腹不限制你显示界面是触屏还是按键。它只关心结果面对一个给定的入侵飞机系统必须在规定时间内、以规定概率、产生规定质量的告警和避让引导。这种“只考行为、不考实现”的思路给供应商留了创新空间也给局方留了统一的审查语言。但副作用是标准里会出现大量“在XX条件下系统应如何表现”的条款这些条款挂在不同的环境、不同的目标动态、不同的本机状态下读起来非常抽象落地时稍不注意就会漏掉一条。2.2 B版相对A版重点修订了什么DO-365初版发布之后行业通过试飞和试点运行积累了很多反馈。A版解决了一部分发现的问题但到B版才算把几个关键矛盾做了实质性处理。从我实际接触到的差异来看我觉得最值得关注的修订方向有这么几个第一告警阈值不再是一个死板固定点而是朝“一组可定义的告警包络”演进。标准给出可接受的包络边界允许申请人根据自己机型的速度范围、机动能力和运行场景在包络内定义具体的OWS告警门限。这个变化对设计者其实是把双刃剑自由度高了一些但证明“我的门限安全”的工作量也更大。第二对链路失联或降级情况下DAA系统应该如何表现B版明显加强了要求。原来的不少逻辑默认数据链路始终可用操作员随时能收到告警但真实运行中C2链路中断、跳变、延迟抖动都会发生。B版需要你在设计里想清楚链路断了以后告警是在机端自动处理还是提前把避让能力下沉到机上。第三多威胁场景的处理被提上桌面。DAA系统不能只在一个入侵目标下工作真实空域里经常同时出现两三个合作目标、一个非合作目标。B版对多目标排序、避免告警轰炸、优先级切换逻辑都提出了更明确的要求。第四与TCAS类设备协调。无人机如果装了应答机或ADS-B OUT有人机上的TCAS会把我们当成普通航空器来协同避让。B版要求DAA的避让引导与TCAS的RA指令不能互相打架预警时机要给TCAS协调留出余量。我不是说上面这四点就是B版变更条款的全部但如果你正在做A版产品的替换升级对着这四个方向先做GAP分析大概率能覆盖大部分需要改动的地方。2.3 A版产品能不能“换个封面”就宣称符合B版答案是肯定不行。我们团队做过一次DO-365A到DO-365B的GAP分析最终涉及改动的需求条目大约占全部DAA需求的五分之一。其中告警阈值、OWS虚警率统计、链路中断场景这三块是重灾区而且这些都不是改改参数就行的往往要动到逻辑结构甚至影响传感器融合层和飞控接口。如果你手里的项目还在早期直接按B版来可以省掉后续返工。如果项目已经按A版开发了一轮建议第一时间把GAP分析表拉出来逐条对照而不是等局方质询时再被动解释。3. 读懂DO-365B核心是这四块3.1 传感器层DAA的“眼睛”不只一种DAA系统的感知来源通常分三类。ADS-B In接收周围飞机的广播式位置信息精度高、更新快但前提是对方装了应答机是“合作目标”。机载雷达探测不依赖对方配合能发现“非合作目标”但探测距离受发射功率、目标雷达反射截面和天气影响。光电/红外传感器是被动式的看得清形态、适合近距离目视确认但作用距离有限云和雾会明显压低性能。DO-365B没有规定你必须要用哪几种但它对“融合后的航迹质量”提出了要求——不能因为某一个传感器丢目标整个航迹就闪烁或断裂。工程上最头疼的问题往往出在传感器航迹关联上雷达看到一个点、ADS-B报告同一个目标两边的经纬度、速度、时间戳不完全一致怎么判断它们是同一个目标切换主传感器的时候怎么避免航迹跳变这些细节写不进标准却是DAA系统能不能稳定输出的关键。3.2 跟踪与威胁评估CPA、DMOD、TTCPA是什么威胁评估的核心不是简单算“现在离我多远”而是算“未来最近会离我多近、多久发生”。三个关键术语要搞懂CPA是最近接近点也就是按当前相对运动趋势本机与入侵机未来最短距离的那个位置TTCPA是到达这个最近接近点还需要的时间DMOD是水平距离修正值用来防止高相对速度下时间阈值过短导致告警滞后。为什么要同时用距离和时间两个维度可以拿开车汇入主路来类比只看后车距离遇到高速接近的车会来不及反应只看后车到达时间又会在远处慢速接近时反复紧张。DAA需要同时评估“最近的横向距离”和“还有多久发生”只有当两者都进入危险门限时才触发高等级告警。这个双门限逻辑听着简单真正调起来很讲究——不同进入角、不同速度组合下同一个目标可能被划进完全不同的威胁等级。3.3 告警优先级与OWS什么该响什么时候响DO-365B体系里告警大致分三个层次。最低一层是交通提示常用于态势感知告诉操作员周边有什么目标不强制回应。中间一层是预警/谨慎告警表示存在潜在冲突操作员需要关注目标动态并准备可能的避让。最高一层是警告以及伴随的避让引导——此时系统不仅告诉你有危险还要给出明确动作建议比如“立即右转20度”或“保持当前航向”。OWS通常指地面站端的操作员告警系统。它的任务不只是“把告警弹出来”而是以正确的优先级、正确的音视频提示、正确的抑制逻辑呈现给操作员。DO-365B对OWS的虚警率和告警疲劳非常关注这点后面第4部分细说。我自己调试过的一型DAA设备警告级门限设在水平CPA约0.35海里、TTCPA约110秒量级。它不是所有系统的标准答案但可以给你一个量级概念——DAA的告警要比TCAS的RA早得多因为远程操作员看到告警、判断情况、发出指令再到飞机真正转弯这中间的时间开销远大于有人机飞行员。告警层级触发情况操作员动作常见表现交通提示目标进入监视范围暂未构成冲突正常监视地图/态势叠加符号无强制告警音预警/谨慎距离或时间接近门限有潜在冲突趋势关注态势准备机动目标高亮、趋势线、提示音警告引导距离和时间均突破危险门限立即执行避让引导或自动驾驶介入明确指令、避让箭头、强化告警音3.4 避让引导与TCAS协调DAA系统的避让机动有一个和TCAS明显不同的特点优先水平避让而不是垂直避让。原因不难理解无人机没有乘客舒适性问题水平改向对周围有人机的影响相对可预测也更容易通过地面站预先判断。更重要的是如果DAA给出垂直机动而对方有人机TCAS也在给垂直RA两个系统可能同时选择同一个高度层反而制造新冲突。DO-365B的协调逻辑着眼点就在这里无人机在有人机TCAS视角里是一个“装有应答机的航空器”人家会认为我们可以配合执行RA。那么DAA在做避让规划时就必须把这种协同因素考虑进去。工程上常见的做法是DAA的告警时机要明显早于对方TCAS RA可能触发的时机让本机在RA前就已经开始机动避免两套防撞逻辑在同一时刻争抢控制权。另外无论系统设计成自动避让还是人工引导避让最终告警链路的受众仍然是人。一个突然在屏幕上跳出来的“正在自动转弯”通知如果没有任何预告和解释地面站里的人是会慌的。好的设计会把自动决策的状态、理由、预期动作都通过OWS一并呈现哪怕系统完全自主也要让操作员始终“跟得上情况”。4. 落地时最容易翻车的三件套告警阈值、时延预算、告警疲劳4.1 告警阈值不能从PDF里直接抄DO-365B给的是允许范围内的包络不是让你直接抄进去的一组具体数字。很多团队拿到标准后看到某个阈值参数就写进需求然后试验一跑告警不是太早就是太晚只能一遍遍改。阈值设太早的后果是飞机还在正常巡航OWS就开始频繁提示操作员的注意力被严重消耗。阈值设太晚的后果更致命留给机动的时间不足避让动作变成大坡度急转甚至突破飞机性能边界。正确的做法是结合本机巡航速度、爬升率、转弯坡度限制、传感器探测距离、链路延迟用蒙特卡洛仿真把不同进入角、不同速度组合全扫一遍画出本机的“告警包络”再与审查方讨论。还有一个容易被忽略的点告警阈值不一定要全飞行阶段统一。进近阶段和航路巡航阶段的目标特征完全不同允许在文件中定义分阶段阈值但前提是切换逻辑要明确且不能因为切换而产生瞬间漏报或重复告警。这个设计决策要尽早做因为它会影响算法、地面站显示和试飞科目设计。4.2 时延预算是全系统的黑洞DAA从“看到目标”到“飞机动作”中间经过的每一环节都在消耗时间传感器采样与更新、融合滤波、威胁评估、数据链下行传输、地面站渲染显示、操作员认知与决策、数据链上行指令、飞控响应、舵面执行。任何一段都可能是短板。我记得项目里一次链路改造下行频率从10Hz提升到20Hz大家以为时延肯定降了结果因为增加了加密和丢包重传机制最差情况下的告警传递延迟反而多了200多毫秒。这种问题不做全链路时延测试根本发现不了。建议把时延预算做成一张表每个环节分别列出“标称值”和“最差值”然后按最差链路累计一遍看告警裕度还能不能撑住。仿真时也要主动注入最差延迟而不是只看理想情况。地面站端还可以做“预测显示”把目标外推位置而不是直接画原始点迹用算法换半秒钟的反应时间。4.3 告警疲劳系统再好人可以不看告警疲劳在DAA项目里是真实存在的运营风险。试飞时我见过这样的场景OWS因为同一批目标反复触发飞手不胜其烦直接在设置里把告警静音了。那一刻我才意识到不管系统算法多严谨、标准符合性多完整只要告警逻辑让人烦一切保护效果都等于零。缓解告警疲劳要在设计层面做几件事。一是同目标冷却时间同一个入侵机在机动处置完成前不要反复弹告警。二是优先级排序多目标场景只呈现最危险的一到两个目标其余放进二级列表而不是一股脑全弹出来。三是告警分级把“需要立即行动”和“需要关注但不着急”严格分开让操作员不用每次听到声音都紧张。B版对OWS虚警率和告警率的关注让这个问题从“使用体验”上升到了“适航符合性”的层面。试飞阶段建议做告警统计每飞行小时告警次数、告警正确率、虚警与漏警比。这些数据既是优化算法的依据也是向局方证明“你的告警系统可被信任”的重要材料。5. 只有PDF不够从标准文本到可取证的系统5.1 把条款拆成需求矩阵DO-365B不是一篇可以“通读领会”的文档而是一套可以逐条编号的需求来源。拿到PDF后第一件事建议是建立“标准条款—系统需求—设计实现—验证方法”的追溯矩阵。每一条与性能、告警、OWS、链路相关的条款都要落到具体的设计描述和验证方法上。这个矩阵的用处在项目初期是帮助团队理解范围在适航沟通阶段就是直接拿出来的证据链。审查方不会因为你说“我们按DO-365B做”就放心他们会挑几条具体条款问你“这条你们怎么实现怎么证明”如果没有追溯矩阵现场翻标准、翻设计、翻测试报告效率极低。5.2 仿真和试飞两条腿走路DO-365B附录里给出了大量针对不同程度威胁的测试场景这些是DAA系统做仿真验证的宝贵输入。实际做法一般是先在仿真环境里把标准场景全部跑一遍记录告警时机、告警类型、避让机动是否符合预期再把最高风险的几个场景搬到试飞里做实飞验证。试飞科目通常围绕威胁飞机的典型运动关系展开对头接近、交叉穿越、同向追逐、高度穿越、爬升进入等。每一类都得覆盖不同速度范围和进入角不能只飞一两条“最标准”的航线。试飞数据里还要同步记录地面站画面、链路质量、操作员操作时间戳才能把“告警到机动”的完整链路还原出来。另外自动避让和人工引导的验证重点不一样。人工引导模式更多验证告警的清晰度、操作员反应时间和执行正确率自动避让模式则要看避让轨迹是否满足最小间隔、机动是否在飞行包线内、避让结束后是否稳定恢复原航线。这两套验证逻辑不要混在一起做否则出了问题不好定位。5.3 给不同角色的一句话行动建议如果你是软件工程师先把OWS告警逻辑、时延预算、链路中断场景这三块摘出来它们是DO-365B里最容易和代码纠缠不清的部分。如果你是系统工程师先画DAA系统架构图把传感器、处理器、链路、地面站、飞控的接口和数据流走通再去看具体性能要求。如果你是适航工程师先做A版到B版的GAP分析表再建立需求追溯矩阵两份文档就是后续所有工作的骨架。如果你是试飞工程师先把标准里的标准测试场景转成试飞任务书再按威胁运动关系设计实飞科目并提前做好告警统计方案。如果你是运营人别陷进技术参数里重点看DAA对运行场景的限制、链路失联后的系统行为、以及告警出现时操作员的处置程序。我第一次做DAA符合性项目时犯过一个挺典型的错误拿到PDF后带着全组从头到尾读标准结果读了一个多月大部分人还是不清楚自己要做什么。后来换了个方式先拉架构图、再列表格、把告警阈值和时延预算单独拎出来反复算最后回头读条款时很多之前晦涩的内容一下就通了。如果你手里也有一份RTCA DO-365B-2021.pdf希望这篇能帮你省下前面那两个星期的弯路。本文还有配套的精品资源点击获取 DO-365B深度解读：无人机DAA系统最低运行性能标准与落地实践
简介RTCA DO-365B-2021是RTCA正式发布的《Detect and Avoid (DAA) Systems 最低运行性能标准MOPS》由SC-228专家委员会编制并于2021年3月批准发布。DAA系统是无人机融入国家空域系统运行的关键技术之一这一标准重点定义了探测、跟踪、告警和避让等功能模块的最低性能要求以及对应的测试与评估方法。资源面向航空电子系统工程师、无人机/有人机融合运行规划人员、适航审定工程师和安全评估人员可用于指导DAA设备研发、系统集成和适航取证。压缩包内包含1个PDF文件大小为18.7MB正文完整、章节清晰便于按需检索。相比2017年初版DO-365B增加了终端区动态无冲突DWC运行、穿越B类空域和地面GBSS支持等修订内容相关更新对实际工程落地尤为重要。目前已有1329人学习下载适合需要系统掌握DO-365B规范的专业技术人群。 上个月整理项目资料时我又翻到那份名为RTCA DO-365B-2021.pdf的文件。收到这份PDF的时候一般不需要附加解释——做无人机整机、地面站或者探测设备的人都知道团队接下来几个月的需求清单基本都得围着“探测与避让Detect and AvoidDAA”这四个字转。DO-365B是RTCA发布的《DAA系统最低运行性能标准MOPS》在2021年的修订版它规定了无人机这套“空中注意力和主动避险系统”必须达到的底线传感器要看到多远的冲突目标、航迹跟踪要稳到什么程度、告警在什么时机响、地面操作员应该收到什么样的引导。凡是打算做超视距运行BVLOS的团队都会在某个节点开始面对这份标准。这篇不打算逐条翻译标准原文而是用我自己做项目、试飞和适航沟通中积累的视角聊聊DO-365B究竟在约束什么、从A版到B版行业在修正什么以及落地时最容易在哪些地方翻车。如果你正打算把这份PDF丢给研发团队或者自己就是那个被丢PDF的人希望这篇能帮你先画出重点。1. 聊DO-365B之前先弄懂DAA在空域里的位置1.1 无人机凭什么安全融入有人机空域有人驾驶飞机之所以能在一个管制空域里安全穿行靠的是“机组人员在驾驶舱里看见并避让”这条基本原则再加上TCAS这类机载防撞系统做最后防线。但无人机的情况完全不同驾驶舱里没有飞行员远程操作员在地面站里既看不到窗外也感知不到飞机的姿态变化和周边态势。尤其到了BVLOS阶段飞机飞出视距之外操作员对周围空中交通的判断几乎全部依赖机载传感器和地面站显示。DAA系统的本质就是把有人机飞行员那套“观察—判断—决策—机动”的闭环用机器重新做一遍。机载传感器负责观察跟踪与威胁评估算法负责判断地面站告警与引导界面负责决策支持最后要么由自动飞行控制执行避让机动要么把避让建议推送给远程操作员。DO-365B就是给这条链路上每个环节定下最低性能及格线。一个比较贴切的类比是有人机像自己开车司机有眼睛还有副驾帮忙看无人机像一个远程代驾车里装了一套自动预警雷达但发号施令的人在几百公里外中间还隔着一条有延迟的数据链路。所以这套系统对预警提前量、告警清晰度、链路断连情况下的表现要求比TCAS苛刻得多。1.2 DO-365B在规则体系里是什么位置RTCA不是政府机构而是由航空工业界、局方、科研单位共同参与的标准组织。DO-365B这种最低运行性能标准本质上是行业共同承认的“可接受的符合性方法”。换句话说当你向局方证明“我的无人机具备DAA能力”时按DO-365B来设计、验证、试飞是当前最主流也最容易沟通的路径之一。要提醒一句DO-365B本身不等于适航批准也不等于运营许可。它解决的是“DAA系统性能是否达标”这个技术判断问题。真正飞上天还需要满足适航规章里关于整机、数据链路、地面站、软件、电磁兼容等方面的要求真正去运营还要满足民航局对运营人、空域、气象、运行程序的批准条件。DO-365B是入场券里最硬的那一张但不是唯一一张。1.3 这份标准到底写给谁我在项目里见过一个现象拿到DO-365B版本的人往往会先把PDF转给软件工程师然后软件工程师看两页就头大了。原因很简单不同角色在这份标准里要关注的东西完全不一样角色最该关注的方向常见误区无人机整机/系统集成DAA系统与飞控、链路的功能接口避让机动执行的边界把DAA当成单独设备不纳入系统架构地面站软件工程师OWS操作员告警、显示符号、告警抑制与交互逻辑只盯界面样式忽略告警率和时延传感器/算法团队探测距离、更新率、航迹融合、威胁评估阈值用实验室指标代替整机环境下的实测指标适航与质量工程师需求追溯、验证方法、符合性材料组织只看结论不看验证边界运营人/飞手DAA对运行场景的限制、告警后的处置程序以为DAA是全自动的完全不用人管我后来带着团队做标准解读时第一步一定是先给每个人画清楚“你只需要吃透哪几章”而不是让大家从头读到尾。2. 从DO-365A到DO-365B到底动了哪几刀2.1 “最低运行性能标准”的潜台词先理解MOPS这三个词里的“性能”二字。它不规定你必须用雷达还是ADS-B接收机不管你的传感器装在机头还是机腹不限制你显示界面是触屏还是按键。它只关心结果面对一个给定的入侵飞机系统必须在规定时间内、以规定概率、产生规定质量的告警和避让引导。这种“只考行为、不考实现”的思路给供应商留了创新空间也给局方留了统一的审查语言。但副作用是标准里会出现大量“在XX条件下系统应如何表现”的条款这些条款挂在不同的环境、不同的目标动态、不同的本机状态下读起来非常抽象落地时稍不注意就会漏掉一条。2.2 B版相对A版重点修订了什么DO-365初版发布之后行业通过试飞和试点运行积累了很多反馈。A版解决了一部分发现的问题但到B版才算把几个关键矛盾做了实质性处理。从我实际接触到的差异来看我觉得最值得关注的修订方向有这么几个第一告警阈值不再是一个死板固定点而是朝“一组可定义的告警包络”演进。标准给出可接受的包络边界允许申请人根据自己机型的速度范围、机动能力和运行场景在包络内定义具体的OWS告警门限。这个变化对设计者其实是把双刃剑自由度高了一些但证明“我的门限安全”的工作量也更大。第二对链路失联或降级情况下DAA系统应该如何表现B版明显加强了要求。原来的不少逻辑默认数据链路始终可用操作员随时能收到告警但真实运行中C2链路中断、跳变、延迟抖动都会发生。B版需要你在设计里想清楚链路断了以后告警是在机端自动处理还是提前把避让能力下沉到机上。第三多威胁场景的处理被提上桌面。DAA系统不能只在一个入侵目标下工作真实空域里经常同时出现两三个合作目标、一个非合作目标。B版对多目标排序、避免告警轰炸、优先级切换逻辑都提出了更明确的要求。第四与TCAS类设备协调。无人机如果装了应答机或ADS-B OUT有人机上的TCAS会把我们当成普通航空器来协同避让。B版要求DAA的避让引导与TCAS的RA指令不能互相打架预警时机要给TCAS协调留出余量。我不是说上面这四点就是B版变更条款的全部但如果你正在做A版产品的替换升级对着这四个方向先做GAP分析大概率能覆盖大部分需要改动的地方。2.3 A版产品能不能“换个封面”就宣称符合B版答案是肯定不行。我们团队做过一次DO-365A到DO-365B的GAP分析最终涉及改动的需求条目大约占全部DAA需求的五分之一。其中告警阈值、OWS虚警率统计、链路中断场景这三块是重灾区而且这些都不是改改参数就行的往往要动到逻辑结构甚至影响传感器融合层和飞控接口。如果你手里的项目还在早期直接按B版来可以省掉后续返工。如果项目已经按A版开发了一轮建议第一时间把GAP分析表拉出来逐条对照而不是等局方质询时再被动解释。3. 读懂DO-365B核心是这四块3.1 传感器层DAA的“眼睛”不只一种DAA系统的感知来源通常分三类。ADS-B In接收周围飞机的广播式位置信息精度高、更新快但前提是对方装了应答机是“合作目标”。机载雷达探测不依赖对方配合能发现“非合作目标”但探测距离受发射功率、目标雷达反射截面和天气影响。光电/红外传感器是被动式的看得清形态、适合近距离目视确认但作用距离有限云和雾会明显压低性能。DO-365B没有规定你必须要用哪几种但它对“融合后的航迹质量”提出了要求——不能因为某一个传感器丢目标整个航迹就闪烁或断裂。工程上最头疼的问题往往出在传感器航迹关联上雷达看到一个点、ADS-B报告同一个目标两边的经纬度、速度、时间戳不完全一致怎么判断它们是同一个目标切换主传感器的时候怎么避免航迹跳变这些细节写不进标准却是DAA系统能不能稳定输出的关键。3.2 跟踪与威胁评估CPA、DMOD、TTCPA是什么威胁评估的核心不是简单算“现在离我多远”而是算“未来最近会离我多近、多久发生”。三个关键术语要搞懂CPA是最近接近点也就是按当前相对运动趋势本机与入侵机未来最短距离的那个位置TTCPA是到达这个最近接近点还需要的时间DMOD是水平距离修正值用来防止高相对速度下时间阈值过短导致告警滞后。为什么要同时用距离和时间两个维度可以拿开车汇入主路来类比只看后车距离遇到高速接近的车会来不及反应只看后车到达时间又会在远处慢速接近时反复紧张。DAA需要同时评估“最近的横向距离”和“还有多久发生”只有当两者都进入危险门限时才触发高等级告警。这个双门限逻辑听着简单真正调起来很讲究——不同进入角、不同速度组合下同一个目标可能被划进完全不同的威胁等级。3.3 告警优先级与OWS什么该响什么时候响DO-365B体系里告警大致分三个层次。最低一层是交通提示常用于态势感知告诉操作员周边有什么目标不强制回应。中间一层是预警/谨慎告警表示存在潜在冲突操作员需要关注目标动态并准备可能的避让。最高一层是警告以及伴随的避让引导——此时系统不仅告诉你有危险还要给出明确动作建议比如“立即右转20度”或“保持当前航向”。OWS通常指地面站端的操作员告警系统。它的任务不只是“把告警弹出来”而是以正确的优先级、正确的音视频提示、正确的抑制逻辑呈现给操作员。DO-365B对OWS的虚警率和告警疲劳非常关注这点后面第4部分细说。我自己调试过的一型DAA设备警告级门限设在水平CPA约0.35海里、TTCPA约110秒量级。它不是所有系统的标准答案但可以给你一个量级概念——DAA的告警要比TCAS的RA早得多因为远程操作员看到告警、判断情况、发出指令再到飞机真正转弯这中间的时间开销远大于有人机飞行员。告警层级触发情况操作员动作常见表现交通提示目标进入监视范围暂未构成冲突正常监视地图/态势叠加符号无强制告警音预警/谨慎距离或时间接近门限有潜在冲突趋势关注态势准备机动目标高亮、趋势线、提示音警告引导距离和时间均突破危险门限立即执行避让引导或自动驾驶介入明确指令、避让箭头、强化告警音3.4 避让引导与TCAS协调DAA系统的避让机动有一个和TCAS明显不同的特点优先水平避让而不是垂直避让。原因不难理解无人机没有乘客舒适性问题水平改向对周围有人机的影响相对可预测也更容易通过地面站预先判断。更重要的是如果DAA给出垂直机动而对方有人机TCAS也在给垂直RA两个系统可能同时选择同一个高度层反而制造新冲突。DO-365B的协调逻辑着眼点就在这里无人机在有人机TCAS视角里是一个“装有应答机的航空器”人家会认为我们可以配合执行RA。那么DAA在做避让规划时就必须把这种协同因素考虑进去。工程上常见的做法是DAA的告警时机要明显早于对方TCAS RA可能触发的时机让本机在RA前就已经开始机动避免两套防撞逻辑在同一时刻争抢控制权。另外无论系统设计成自动避让还是人工引导避让最终告警链路的受众仍然是人。一个突然在屏幕上跳出来的“正在自动转弯”通知如果没有任何预告和解释地面站里的人是会慌的。好的设计会把自动决策的状态、理由、预期动作都通过OWS一并呈现哪怕系统完全自主也要让操作员始终“跟得上情况”。4. 落地时最容易翻车的三件套告警阈值、时延预算、告警疲劳4.1 告警阈值不能从PDF里直接抄DO-365B给的是允许范围内的包络不是让你直接抄进去的一组具体数字。很多团队拿到标准后看到某个阈值参数就写进需求然后试验一跑告警不是太早就是太晚只能一遍遍改。阈值设太早的后果是飞机还在正常巡航OWS就开始频繁提示操作员的注意力被严重消耗。阈值设太晚的后果更致命留给机动的时间不足避让动作变成大坡度急转甚至突破飞机性能边界。正确的做法是结合本机巡航速度、爬升率、转弯坡度限制、传感器探测距离、链路延迟用蒙特卡洛仿真把不同进入角、不同速度组合全扫一遍画出本机的“告警包络”再与审查方讨论。还有一个容易被忽略的点告警阈值不一定要全飞行阶段统一。进近阶段和航路巡航阶段的目标特征完全不同允许在文件中定义分阶段阈值但前提是切换逻辑要明确且不能因为切换而产生瞬间漏报或重复告警。这个设计决策要尽早做因为它会影响算法、地面站显示和试飞科目设计。4.2 时延预算是全系统的黑洞DAA从“看到目标”到“飞机动作”中间经过的每一环节都在消耗时间传感器采样与更新、融合滤波、威胁评估、数据链下行传输、地面站渲染显示、操作员认知与决策、数据链上行指令、飞控响应、舵面执行。任何一段都可能是短板。我记得项目里一次链路改造下行频率从10Hz提升到20Hz大家以为时延肯定降了结果因为增加了加密和丢包重传机制最差情况下的告警传递延迟反而多了200多毫秒。这种问题不做全链路时延测试根本发现不了。建议把时延预算做成一张表每个环节分别列出“标称值”和“最差值”然后按最差链路累计一遍看告警裕度还能不能撑住。仿真时也要主动注入最差延迟而不是只看理想情况。地面站端还可以做“预测显示”把目标外推位置而不是直接画原始点迹用算法换半秒钟的反应时间。4.3 告警疲劳系统再好人可以不看告警疲劳在DAA项目里是真实存在的运营风险。试飞时我见过这样的场景OWS因为同一批目标反复触发飞手不胜其烦直接在设置里把告警静音了。那一刻我才意识到不管系统算法多严谨、标准符合性多完整只要告警逻辑让人烦一切保护效果都等于零。缓解告警疲劳要在设计层面做几件事。一是同目标冷却时间同一个入侵机在机动处置完成前不要反复弹告警。二是优先级排序多目标场景只呈现最危险的一到两个目标其余放进二级列表而不是一股脑全弹出来。三是告警分级把“需要立即行动”和“需要关注但不着急”严格分开让操作员不用每次听到声音都紧张。B版对OWS虚警率和告警率的关注让这个问题从“使用体验”上升到了“适航符合性”的层面。试飞阶段建议做告警统计每飞行小时告警次数、告警正确率、虚警与漏警比。这些数据既是优化算法的依据也是向局方证明“你的告警系统可被信任”的重要材料。5. 只有PDF不够从标准文本到可取证的系统5.1 把条款拆成需求矩阵DO-365B不是一篇可以“通读领会”的文档而是一套可以逐条编号的需求来源。拿到PDF后第一件事建议是建立“标准条款—系统需求—设计实现—验证方法”的追溯矩阵。每一条与性能、告警、OWS、链路相关的条款都要落到具体的设计描述和验证方法上。这个矩阵的用处在项目初期是帮助团队理解范围在适航沟通阶段就是直接拿出来的证据链。审查方不会因为你说“我们按DO-365B做”就放心他们会挑几条具体条款问你“这条你们怎么实现怎么证明”如果没有追溯矩阵现场翻标准、翻设计、翻测试报告效率极低。5.2 仿真和试飞两条腿走路DO-365B附录里给出了大量针对不同程度威胁的测试场景这些是DAA系统做仿真验证的宝贵输入。实际做法一般是先在仿真环境里把标准场景全部跑一遍记录告警时机、告警类型、避让机动是否符合预期再把最高风险的几个场景搬到试飞里做实飞验证。试飞科目通常围绕威胁飞机的典型运动关系展开对头接近、交叉穿越、同向追逐、高度穿越、爬升进入等。每一类都得覆盖不同速度范围和进入角不能只飞一两条“最标准”的航线。试飞数据里还要同步记录地面站画面、链路质量、操作员操作时间戳才能把“告警到机动”的完整链路还原出来。另外自动避让和人工引导的验证重点不一样。人工引导模式更多验证告警的清晰度、操作员反应时间和执行正确率自动避让模式则要看避让轨迹是否满足最小间隔、机动是否在飞行包线内、避让结束后是否稳定恢复原航线。这两套验证逻辑不要混在一起做否则出了问题不好定位。5.3 给不同角色的一句话行动建议如果你是软件工程师先把OWS告警逻辑、时延预算、链路中断场景这三块摘出来它们是DO-365B里最容易和代码纠缠不清的部分。如果你是系统工程师先画DAA系统架构图把传感器、处理器、链路、地面站、飞控的接口和数据流走通再去看具体性能要求。如果你是适航工程师先做A版到B版的GAP分析表再建立需求追溯矩阵两份文档就是后续所有工作的骨架。如果你是试飞工程师先把标准里的标准测试场景转成试飞任务书再按威胁运动关系设计实飞科目并提前做好告警统计方案。如果你是运营人别陷进技术参数里重点看DAA对运行场景的限制、链路失联后的系统行为、以及告警出现时操作员的处置程序。我第一次做DAA符合性项目时犯过一个挺典型的错误拿到PDF后带着全组从头到尾读标准结果读了一个多月大部分人还是不清楚自己要做什么。后来换了个方式先拉架构图、再列表格、把告警阈值和时延预算单独拎出来反复算最后回头读条款时很多之前晦涩的内容一下就通了。如果你手里也有一份RTCA DO-365B-2021.pdf希望这篇能帮你省下前面那两个星期的弯路。本文还有配套的精品资源点击获取