1. AVB协议栈概述：车载以太网背景、AVB协议栈的定位与价值、与传统车载网络的对比
各位同学，大家好。我是你们这门课的老朋友。今天咱们正式开篇，聊聊AVB协议栈。
说实话，每次讲这个章节，我都会想起自己刚入行那会儿。那时候车载网络还是CAN的天下，谁能想到今天以太网会杀进来？嗯，技术这东西，变化真快。
1.1 车载以太网背景：为什么是它？
先说说背景。为什么车载网络要引入以太网？
你想想看，现在的车已经不是单纯的交通工具了。智能座舱、自动驾驶、高清环视、OTA升级……这些功能对带宽的要求，传统总线根本扛不住。
- 带宽需求爆炸：一个高清摄像头，每秒产生的数据量就是几百兆。CAN总线最高才1Mbps，你说怎么传？
- 实时性要求高：自动驾驶的传感器数据，延迟超过几毫秒就可能出事故。传统以太网虽然带宽大，但延迟不可控。
- 线束成本压力：传统车用LVDS线缆又粗又贵。以太网用一对双绞线就能搞定，成本低、重量轻。
我在一个项目里遇到过，客户要求用CAN传输环视摄像头的视频流。折腾了两个月，最后发现根本不可能。后来换成车载以太网，一周就搞定了。说白了，技术选型不能逆天而行。
核心结论：车载以太网不是来替代CAN的，而是来填补高带宽、低延迟这个空白的。
1.2 AVB协议栈的定位与价值
好，那AVB协议栈又是干嘛的？
车载以太网本身只是一个物理层和数据链路层的标准。它只管把数据从A点搬到B点。但怎么保证搬过去的数据不丢、不乱、不延迟？这就需要上层协议来管了。
AVB，全称是Audio Video Bridging，后来演变成TSN（Time-Sensitive Networking）。它的核心价值就四个字：确定性通信。
什么意思？
- 时间同步：所有节点共享同一个时钟，误差在微秒级。没有这个，音视频同步就是空谈。
- 带宽预留：给关键数据流预留固定的带宽，保证不丢包。我记得有个项目，客户说“我的音频偶尔卡顿”，查了半天，就是带宽没预留好。
- 流量整形：控制数据发送的节奏，避免突发流量把网络冲垮。
- 延迟控制：端到端延迟可以控制在2ms以内，这对ADAS系统至关重要。
个人经验：我建议初学者先别急着看代码，先把AVB的定位搞清楚。它不是一个万能协议，它只解决“实时音视频传输”这个特定场景。你非要用它传控制指令，那不如直接用CAN。
1.3 与传统车载网络的对比
咱们来做个对比，这样更直观。
| 特性 | CAN | CAN FD | LIN | FlexRay | 车载以太网（AVB） |
|---|---|---|---|---|---|
| 最大带宽 | 1 Mbps | 8 Mbps | 20 kbps | 10 Mbps | 100 Mbps / 1 Gbps |
| 实时性 | 事件触发 | 事件触发 | 主从轮询 | 时间触发 | 时间同步 + 预留 |
| 典型延迟 | ~100 μs | ~50 μs | ~5 ms | ~10 μs | ~2 ms（可控） |
| 应用场景 | 控制指令 | 诊断、刷写 | 车窗、座椅 | 线控制动 | 音视频、ADAS |
| 线束成本 | 低 | 低 | 极低 | 高 | 中 |
你看这个表，一目了然。CAN的优势在控制指令，便宜、可靠。但到了音视频领域，它就是有心无力。
我曾经在一个项目中，用CAN传音频数据。为了压缩到1Mbps以内，音频质量降得一塌糊涂。客户验收时直接说“这声音像从收音机里传出来的”。后来换成AVB，同样的音频源，效果天壤之别。
避坑指南：千万不要以为AVB可以完全替代CAN。它们各司其职。我见过有人想把所有信号都走以太网，结果成本飙升，可靠性还下降了。记住，合适的才是最好的。
1.4 AVB协议栈的组成
最后简单说一下AVB协议栈的组成。后面我们会逐章深入，这里先有个整体印象。
- IEEE 802.1AS：时间同步协议。所有节点对时，误差在1μs以内。
- IEEE 802.1Qav：流量整形协议。控制数据发送的节奏，避免拥塞。
- IEEE 802.1Qat：流预留协议。为关键数据流预留带宽。
- IEEE 1722：音视频传输协议。把音视频数据封装成以太网帧。
- IEEE 1733：RTP over AVB。基于RTP的实时传输。
嗯，这里要注意，AVB协议栈不是孤立的。它需要底层的以太网硬件支持，也需要上层的应用配合。我建议你在学习时，先搭一个最小系统，把时间同步跑通，再逐步添加其他功能。
好了，第一章就到这里。下一章我们开始动手，搭建AVB的开发环境。到时候我会分享一些我踩过的坑，保证让你少走弯路。