二、系统架构基础：航空电台的硬件组成、软件分层架构、通信协议栈简介
好，咱们进入正题。这一章我打算聊聊航空电台的“骨架”和“灵魂”。说白了，就是它由哪些硬件拼起来的，软件又是怎么一层层叠上去的，以及那些看不见的协议到底在干什么。
我刚开始接触航空电台时，觉得这东西就是个高级对讲机。后来拆开一台老设备，才发现里面门道深着呢。嗯，咱们一步步来。
2.1 硬件组成：那些你看得见和看不见的板子
一台典型的航空电台，从硬件上看，可以分成几个核心模块。我个人习惯把它们分成“射频前端”、“基带处理”、“控制与接口”和“电源管理”四大块。
| 模块 | 核心器件 | 我的理解 |
|---|---|---|
| 射频前端 | 功放、低噪放、滤波器、天线调谐器 | 负责把信号发出去、收进来。功率大，发热也大 |
| 基带处理 | FPGA、DSP、ADC/DAC | 数字信号处理的核心。调制解调、编解码都在这 |
| 控制与接口 | ARM/MCU、以太网、ARINC 429、串口 | 管逻辑、管通信、管人机交互 |
| 电源管理 | DC-DC模块、LDO、浪涌保护 | 28V直流进来，变成各路电压。这模块出问题，整机罢工 |
这里我想特别提一下射频前端。我在项目中遇到过一台电台，发射功率老是掉。查了半天，发现是功放管的散热硅脂干了。你想想看，高空温度低，地面温度高，热胀冷缩，硅脂就慢慢失效了。所以后来我设计时，都会要求用导热垫片代替硅脂。
2.2 软件分层架构：别让代码变成一锅粥
航空电台的软件，如果写成一个大循环，那维护起来就是噩梦。我见过最老的设备，代码全在一个文件里，改个参数要重新编译整个固件。后来行业里慢慢形成了分层架构，说白了就是各管各的，互不干扰。
典型的软件分层是这样的：
- 硬件抽象层（HAL）：直接操作寄存器、GPIO、SPI。换芯片时，只改这一层。
- 驱动层：封装外设操作，比如“读频率”、“写功率”。
- 协议栈层：处理ARINC 429、以太网、串口协议。数据进来，解析成内部消息。
- 业务逻辑层：真正的“大脑”。频率管理、模式切换、故障诊断都在这里。
- 应用层：人机界面、远程控制接口、日志记录。
我建议你在设计初期就把分层定死。层与层之间用接口通信，不要跨层调用。举个例子，应用层想读当前频率，不能直接去读寄存器，必须通过业务逻辑层去调用驱动层。为什么？因为寄存器地址可能变，但接口不会变。
2.3 通信协议栈简介：数据是怎么“说人话”的
航空电台的通信协议栈，和咱们平时用的TCP/IP有点像，但更严格、更实时。我把它简化成四层模型：
- 物理层：决定用什么频率、什么调制方式。比如VHF频段用AM调制，HF频段用SSB。
- 链路层：负责帧同步、差错控制。航空里常用的是HDLC的变种，加上CRC校验。
- 网络层：路由和寻址。多跳通信时，数据包怎么走？这层说了算。
- 应用层：具体业务，比如语音通信、数据链、远程维护指令。
这里有个坑，我踩过。有一次做远程升级，数据包总是传不全。查了半天，发现是链路层的超时重传机制没调好。默认的超时时间是100ms，但我们的数据链路由经过卫星，延迟有300ms。结果每次重传都撞在一起，越传越乱。
最后说一句，协议栈的每一层都有它的职责。不要为了省事，把链路层的功能塞到应用层去做。那样做，短期看是快了，长期看是给自己埋雷。
嗯，这一章就到这里。下一章咱们聊聊远程维护的具体实现，包括怎么安全地升级固件、怎么诊断故障。到时候我会拿一个真实案例来讲，保证比看手册有意思。