1. 为什么平台化是PMR行业绕不开的一步棋前段时间在整理项目资料时翻到一份早期的设计方案看着上面密密麻麻的专用芯片选型和一板一方案的硬件拓扑再对比现在手上这套新的通用平台说实话感慨挺多的。这个行业里做专业移动无线电PMR设备的老工程师应该都有同感过去十年我们每接一个新项目几乎都要从芯片选型重新开始——DMR 项目选一版方案TETRA 项目换一套平台应急自组网项目又得推倒重来。硬件改版周期动辄两三个月软件适配再搭进去一两个月等产品能跑通市场窗口早就关了一半。这也是我关注New PMR Common Platform Processor这个方向的原因。所谓 Common Platform Processor翻译成大白话就是用一套统一的硬件核心和软件框架去承载不同制式、不同频段、不同应用场景的 PMR 产品。它不是一个具体的芯片型号——虽然底层确实需要一款足够强力的处理器——而是一整套设计理念把通信协议栈、语音处理、射频控制和业务应用全部抽象到通用平台上让窄带对讲、宽带多媒体、公专融合这些原本泾渭分明的产品线在同一个底座上生长出来。这篇文章我想从我们团队实际推进这个平台的经历出发聊聊硬件骨架怎么搭、协议栈怎么做多模融合、射频前端有哪些坑、认证和量产环节有什么容易被忽视的细节。如果你也在做专网通信设备的平台化预研或者正在为下一代产品选型核心处理器这篇文章应该能给你一些参考。先给出一个总体的判断PMR 平台化这件事技术难点不在某一颗芯片的性能上而在于如何在通用和专业之间找到平衡。通用意味着要牺牲一部分极致优化专业意味着很多垂直需求不能妥协——这个平衡点就是整个平台架构设计的灵魂。2. 硬件骨架的核心设计应用处理器与基带处理器的分工逻辑2.1 从分立方案到融合方案的变化国内主流 PMR 终端在过去很长一段时间里都采用分立方案一颗 MCU 跑协议栈和应用逻辑一颗 DSP 做语音编解码再加一颗 FPGA 或专用基带芯片处理调制解调。这个方案的优点是每一部分都可以选最合适的器件缺点也很明显——板面积大、功耗高、物料成本压不下来而且三颗芯片之间的接口通信会成为整个系统的性能瓶颈。新的通用平台处理器方案则把大部分功能集成到一款高性能 SoC 中。以我们目前使用的平台为例它内部包含了一个多核 ARM Cortex-A 系列应用处理器和一个独立的数字信号处理内核两者通过片内高速总线互联外部只需要搭配一颗射频收发器和对应的前端匹配电路。对比来看这样的优势相当直接对比维度传统分立方案通用平台方案PCB 面积三颗主芯片外围约 8~10 平方厘米单芯片射频前端约 4~5 平方厘米整机功耗1.2W~1.8W待机0.8W~1.0W待机协议栈切换需更换或重烧 DSP 固件软件配置切换秒级完成多模并发极难实现可通过多核分配实现BOM 成本高涉及多个供应商集中采购议价空间大二次开发难度高需同时掌握三种芯片中主攻一套 SDK但这里要强调一点把基带处理和应用处理集成到一颗芯片里并不意味着传统的基带和应用概念消失了而是它们的边界变成了软件逻辑上的分区不再是物理上的两颗芯片。这对系统架构设计提出了更高的要求。2.2 多核资源的划分原则在实际设计多模 PMR 平台时我们遵循的核心原则是时延敏感的任务就近于中断源算力密集的任务靠近专用加速单元。以 DMR 协议栈的物理层处理为例同步字检测和比特判决这类任务要求在微秒级完成哪怕延迟 100 微秒都会导致帧同步失败。这类任务必须由处理器的实时内核或 DSP 内核专门承接并且中断路径上不能有任何可能产生阻塞的操作。在我们的平台里物理层处理被划分到一颗运行裸机程序的 Cortex-R 内核上不跑操作系统不做任务调度纯粹处理中断和实时信号——这是保障通信质量的第一道防线。协议栈上层MAC 层、数据链路层和数据业务应用则分配到运行 Linux 的 Cortex-A 内核上。这部分对实时性的要求从微秒级放宽到毫秒级Linux 的 PREEMPT_RT 补丁完全能够满足。同时Linux 生态带来的最大好处是应用开发的便利性——团队里做上层应用的工程师不需要理解物理层是如何实现的他们只需要调用平台提供的 API 接口就像开发手机 App 一样。多内核之间的通信机制也要特别注意。平台一般会提供共享内存加消息队列的 IPC 方案但使用这些机制时最常踩的坑是优先级反转和缓存一致性问题。我们的经验是实时内核和应用处理器内核之间的关键消息通道必须使用无锁环形缓冲区并且通过硬件信号量来做同步数据量大的语音帧和定位数据走共享内存的 DMA 通道但启动 DMA 传输前一定要做 cache clean 操作否则会出现偶发的数据错乱——这类问题在实验室里极难复现一旦进入外场测试在温度、振动、信号环境变化的情况下就彻底暴露出来了。3. 多模协议栈架构一套代码如何兼容 DMR、TETRA 与自组网3.1 协议栈分层的核心思想PMR 领域从来不是一种制式通吃天下的格局。公共安全领域大量使用 TETRA 和 P25工商业用户普遍采用 DMR应急通信场景又需要支持自组网和宽带多媒体。作为终端厂商如果每一套制式都重新维护一套协议栈代码版本管理将是灾难级的——我在上一个项目里就经历过同时维护 DMR 和模拟 FM 两套代码的痛苦加一个新功能要改两个地方改完还要分别做回归测试效率极低。新的平台在设计初期就确定了协议栈的抽象层次模型。整体上分为三层共性服务层承载所有制式都通用的能力包括语音编解码、GPS/北斗定位数据处理、加密鉴权框架、电池管理与电源策略等。这一层的代码在整个平台中占比约 40%是真正的家底。制式适配层每个制式有一个独立的适配模块负责将该制式的协议原语映射到共性服务层的统一调用接口上。比如 DMR 的呼叫控制原语和 TETRA 的呼叫控制原语经过适配层转换后对上层暴露的是完全一致的 API。业务应用层面向最终用户的功能实现如组呼、单呼、紧急呼叫、短消息、GPS 上报等。应用层开发人员完全不需要关心底层是什么制式只需要调用统一 API。这套分层的价值在真正做多模终端时才体现得淋漓尽致。我们做的第一款型号同时支持 DMR 和模拟 FM由于分层架构清晰整个软件适配只花了两周时间而我之前参与的项目从模拟转 DMR光是通信协议部分的改造就耗费了将近四个月。3.2 多模切换的状态机设计多模终端最核心的体验问题不是每一种制式单独的通信质量如何而是不同制式之间切换时会不会掉线、会不会错过呼叫。这个问题做不好用户会直接质疑整机的可靠性——毕竟专网通信的钱是花在关键时刻必须连通上的。我们在平台上实现的是一种双栈待机 优先级仲裁的机制。所谓双栈待机就是接收链路同时在监听两种制式的控制信道而不是简单地在两种制式之间做时分切换。这在传统分立芯片方案上几乎不可能实现因为接收链路只有一条但在新的平台处理器架构下由于射频前端支持双接收通道配合处理器的多核处理能力可以让一个内核专门监听 DMR 控制信道另一个内核监听模拟 FM 的亚音频信号。两者各自独立工作由仲裁模块根据当前业务状态决定将用户业务切换到哪一路。仲裁策略的设计是整套机制里最有讲究的部分。我们早期实现的策略是优先级绝对制即 TETRA 呼叫永远优先于 DMR 呼叫DMR 呼叫永远优先于模拟 FM。但在实际用户反馈中发现这种策略并不符合真实使用习惯——用户正在 DMR 信道上进行关键的数据传输时如果突然被模拟 FM 的语音呼叫打断他反而会很恼火。后来我们改为当前业务优先 紧急呼叫抢占的策略正在进行语音呼叫时除非另一制式出现紧急呼叫Emergency Call否则不进行抢占待当前呼叫结束后再按优先级队列处理等待中的呼叫请求。表多模切换的仲裁策略对比场景早期策略绝对优先级最终策略业务优先DMR 数据传输中FM 语音呼入立即切换至 FM数据传输中断数据传输完成后再应答 FMFM 语音通话中DMR 组呼发起立即切换至 DMRFM 通话中断当前通话自然结束后再接入 DMR任意状态收到紧急呼叫立即切换立即切换无差别抢占这个改动看着很小但直接影响了外场测试中用户的接受度评价也让我们意识到协议栈设计不能只考虑技术指标还要深入理解目标用户的工作流程与使用习惯。3.3 语音编解码的共享与切换多模平台另一个容易忽略的问题是语音编解码的兼容性。DMR 使用 AMBE2 声码器TETRA 使用 ACELP模拟 FM 几乎不需要语音压缩直接模拟调频传输。传统方案中每一套制式都配备独立的声码器芯片平台化设计中则由软件声码器统一处理。这里有一个性能上的现实问题软件声码器对处理器的算力要求不低尤其是 AMBE2 的编码过程涉及大量的语音特征提取运算。如果平台选用的处理器主频和 DSP 能力不足在高负载场景下比如同时进行语音编码和 GPS 数据压缩上报就会出现语音帧处理超时表现为通话断续。我们在选型时对这块做了专门的基准测试。要求在 DMR 全速率语音编码的同时持续跑一组 CPU 密集型任务模拟 GPS 数据加密和协议封装声码器处理延迟必须控制在 30ms 以内。当时对比了多个处理器候选最终从实测数据来看高下立刻见分晓。我的经验是考察 PMR 平台处理器时不要只看主频和核心数一定要把声码器的软件实现拉出来跑基准单独测一下它在特定负载下的最坏情况时延而不仅仅是平均时延。4. 射频前端的适配设计不同频段、不同功率等级如何共板4.1 射频收发器的选型与匹配网络通用平台处理器的核心是数字基带部分但要形成真正的产品必须有配套的射频前端方案。PMR 频段非常分散——VHF 频段136-174MHz、UHF 频段400-470MHz、TETRA 频段380-430MHz / 806-870MHz、700MHz 宽带频段——每套频段对射频器件的需求都不同。在新平台的设计中我们采用的策略是一颗收发器 可重构匹配网络。收发器选用宽带射频芯片其内部集成了可编程的锁相环和混频器能够覆盖 30MHz 到 6GHz 的宽频范围。匹配网络则根据不同频段在硬件设计时预留多组参数通过处理器的 GPIO 控制射频开关进行切换。这样做的好处是同一块主板只需要更改匹配网络参数和滤波器型号就能适配不同地区、不同用户的频段需求而不需要重新设计整块 PCB。这里我想特别提醒一个细节天线接口的静电防护ESD。PMR 终端经常在户外使用天线端口直接暴露在环境中雷击感应和静电放电的威胁比消费电子产品严重得多。我们的整机在做 ESD 测试时天线端 ±8kV 接触放电必须保证不死机、不丢失通信。这要求射频前端设计时必须预留 TVS 管的位置同时 PCB 布局上天线馈线的走线要尽量短避免引入额外的寄生电感。4.2 功率放大器的线性化与效率平衡不同制式对发射功率和线性度的要求不同。DMR 由于采用 4FSK 调制对功放的线性度要求相对宽松可以使用效率更高的 C 类功放TETRA 使用 π/4-DQPSK 调制线性度要求严格得多必须使用 AB 类功放或加入数字预失真DPD技术。通用平台方案中射频前端需要兼容这两种截然不同的需求。我们最终的方案是基带处理器中集成了 DPD 算法模块通过自适应预失真补偿功放的非线性特性。发射链路用一颗 AB 类功放在 DMR 模式下DPD 可以关闭让功放工作在近饱和区以获得更高效率在 TETRA 模式下DPD 模块自动启用将邻道功率泄漏比ACPR压制到指标要求以内。DPD 的调试是个细活尤其是多频段共用一套 DPD 模型时不同频段的温度漂移特性差异会让一套固定的预失真参数失效。我们最终采用的方法是在每个频段的校准阶段分别采集 25℃、-20℃、60℃ 三组温度点的功放特性曲线存入校准区设备运行时根据实时温度传感器数据在相邻两组曲线之间做线性插值动态更新 DPD 参数。这套方法在实验室实测中将 ACPR 的温漂控制在 3dB 以内远好于固定参数方案的 8dB 漂移。4.3 灵敏度性能的实战调优射频灵敏度的调试是整机研发中最磨人的环节之一。平台处理器的集成度高意味着数字电路和模拟射频电路的物理距离很近数字噪声对接收链路的干扰就成为一个明显问题。我们第一版 PCB 的实测灵敏度就非常不理想在 UHF 频段比指标要求差了 6dB——这个差距在专网通信中是致命的意味着通信距离直接缩水三分之一以上。排查过程的最终定位是DDR 内存总线的谐波分量耦合到了射频接收通道。处理器平台的内存总线频率在 800MHz 左右它的高阶谐波恰好落在了 UHF 接收频段内。解决措施包括三个方面在 PCB 布局上将射频前端与 DDR 内存颗粒分置在板卡的两侧增加物理隔离距离。在 DDR 供电线上增加多级磁珠和电容滤波抑制电源平面的噪声传导。优化处理器内部的 DDR 驱动强度设置降低总线边沿的振铃幅度。经过这三项整改灵敏度提升了约 5dB勉强压线达标。但说实话即使到现在这个问题的彻底解决程度仍然主要依赖于 PCB 布局的经验而不是单纯靠芯片特性就能规避。在平台化方案中一定要在 layout 阶段就考虑到数字噪声对射频的干扰不要等到调机阶段再来补救那时可用的手段就非常有限了。表射频灵敏度优化前后对比优化项优化前优化后接收灵敏度UHF 频段-112dBm-118dBmDDR 谐波耦合电压2.4mV0.6mV主板布局射频与 DDR 同侧分置两侧电源纹波45mVpp18mVpp5. 认证与实战检验通用平台最难的不是技术而是流程5.1 多制式认证的复用策略PMR 产品要进入市场需要过的认证关卡非常多无线电型号核准、入网认证、防爆认证如应用于石油化工场景的 Ex 认证、环境可靠性认证等。在传统方案中每推出一款新制式的产品所有认证都要从头再来一遍。新平台的架构优势在于同一款硬件变更的只是软件配置和射频匹配参数核心硬件与部分软件模块保持完全一致。我们实际操作的策略是先拿一款覆盖最高规格频段和制式组合的型号去跑全套认证拿到证书后其他型号在申请认证时只需要做差异部分的检测。比如基本型 DMR 终端和 DMR模拟 FM 双模终端两者在射频指标、EMC 指标上的表现非常接近认证机构在审核时可以部分采信已有报告大幅缩短了认证周期。5.2 外场测试中常见的可靠性问题实验室指标达标只是第一步专网产品真正要被用户接受必须在外场严苛环境中经得住考验。我们做过一款面向港口用户的 DMR 终端外场测试时出现了一个非常奇怪的故障设备在龙门吊附近工作时偶尔会出现通话中断重启后恢复正常。但是这种场景在实验室里怎么都复现不出来。经过深入排查最终定位到是电磁环境中的强脉冲干扰导致的处理器内核异常复位。港口的龙门吊有大型变频电机启动瞬间会产生强烈的电磁脉冲能量耦合进终端后干扰了处理器电源监控电路使其产生了一次虚假的欠压复位信号。我们的解决方法是双管齐下硬件上在电源入口处增加一级瞬态抑制二极管TVS并调整电源监控芯片的滤波参数避免其对微秒级的瞬态干扰误响应软件上为内核增加看门狗自恢复机制即使发生异常复位也能在 500ms 内自动恢复通信功能——对于正在进行的通话这仍然会造成短暂中断但至少不像之前那样需要手动重启才能恢复。5.3 量产一致性的把控最后一个要分享的是量产阶段的经验。平台化设计带来的一个隐藏风险是核心硬件的一致性通常很好但射频前端的组装一致性往往被忽略。批量生产中贴片功率放大器的焊接质量、天线连接座的装配力矩差异都会导致最终产品的发射功率和灵敏度出现偏差。我们在生产线上增加了三道把控环节每台整机在产线上必须完成全频段发射功率校准校准数据写入设备 EEPROM。抽检环节增加了灵敏度测试按批次抽检比例不低于 3%。对天线连接座的装配采用扭矩螺丝刀并设置力矩范围标记防止松动。这些措施看起来琐碎但对出货质量的稳定性起到了决定性作用。我们有段时间曾经因为忽略了天线座装配力矩的管控导致某批次 2000 台设备中约有 60 台出现信号弱的问题客户投诉率一下子飙了上来。从那以后产线校验的流程就再也没有简化过。6. 后续演进的思考宽带化与公专融合的预留6.1 宽带数据能力的扩展空间目前的平台主要解决的是窄带 PMR 制式的通用化问题但长远来看宽带多媒体集群B-TrunC、公专融合等方向已经是大势所趋。专网用户不再满足于语音和短数据他们对实时视频回传、宽带数据采集、GIS 地图调度这些业务的需求正在快速增长。新平台在架构设计时已经为此做了预留。处理器中集成了一颗独立的 GPU 和视频编解码单元配合 LTE 或 5G 模组可以实现宽带数据业务的接入。更重要的是由于采用了统一的多模架构宽带模组在系统中被视为github 一种新的制式接入通道与 DMR/TETRA 共用同一套业务应用层接口。这样当用户需要从窄带终端升级到公专融合终端时应用层的代码基本不用改动只需要在制式适配层增加宽带模块的适配代码。6.2 平台化带来的研发模式变革平台化不仅是技术架构的变化也深刻影响了团队的研发组织方式。过去按产品线划分的研发团队彼此之间代码不共享技术积累互不相通在平台化之后团队逐步转向按技术域划分——有专门的射频组、基带组、协议组、应用组每个组面对的是整个产品矩阵而非单一型号。这种变化带来的一个好处是某个技术域的专家能够深入钻研得更透彻。比如我们的射频调优工程师以前只能在单个项目中积累经验现在可以同时从多个型号的调试数据中交叉验证总结出更通用的射频设计规范。而协议组则能从 DMR、TETRA、模拟 FM 的对比中抽象出共性需求不断提升制式适配层的代码质量和复用率。从实际研发效率来看平台化落地后的新项目导入周期从需求确认到样机点亮缩短了至少 40%。对一家以快速响应市场为生存法则的专网设备厂商来说这个数字带来的竞争意义是巨大的。6.3 给正在选型或启动平台化项目的同行几点建议按照我们走过的路有几条经验可以作为参考第一选型时不要只盯芯片的纸面参数。把协议栈、声码器、DPD 这些核心算法的实际运行性能都跑一遍基准特别是最坏情况时延和功耗比什么都重要。第二平台化要作为一把手工程来推。它涉及产品规划、硬件设计、软件开发、测试验证、生产制造的全链条重塑。如果只是硬件组或软件组在推动很容易在中途被传统的项目流程拉回老路。第三为第一版平台预留足够的打磨时间。我们第一版平台从启动到稳定经历了约 18 个月中间有大量时间花在解决集成度提高带来的射频干扰、内核间通信稳定性这类问题上。这比传统方案的开发周期长不少但后续每一次新产品导入节省下来的时间都会把前期的投入补回来。第四重视软件生态的构建。平台的价值一半在硬件另一半在配套的 SDK、调试工具、文档体系。研发团队能否高效使用平台很大程度上取决于软件工具的完善程度。我们在这方面投入了专门的人力做文档化和工具链建设现在看来非常值得。我自己在带这个平台项目的过程中最深的一个体会是做通用平台处理器表面上是在做技术选型和硬件设计本质上是在做平衡——在性能和通用性之间平衡在研发效率和产品差异化之间平衡在短期交付和长期积累之间平衡。每一步都要做出取舍而只有把取舍的依据想透彻了整个平台才能真正立得住并成为后续产品矩阵的坚实底座。