第1章：AUTOSAR概述与以太网背景
1.1 AUTOSAR经典平台与自适应平台简介
做车载嵌入式开发的朋友，对AUTOSAR这个词肯定不陌生。但说实话，很多人一听到AUTOSAR就觉得头大——分层太多、配置太复杂。我刚开始接触时也是这个感觉。
AUTOSAR其实分两个大方向：经典平台（Classic Platform）和自适应平台（Adaptive Platform）。这两个东西，说白了就是给不同需求的车载系统准备的。
经典平台，我习惯叫它“老大哥”。它主要跑在微控制器（MCU）上，比如Infineon的TC3xx、NXP的S32K系列。这类芯片资源有限，但实时性要求极高。你想想看，安全气囊、刹车系统这些，能容忍延迟吗？绝对不能。经典平台就是为这类硬实时任务设计的。
我在项目中遇到过一件事：有个同事把以太网协议栈直接堆在经典平台上，结果CPU负载飙到90%。后来才发现，经典平台更适合CAN、LIN这类轻量级总线。以太网嘛，还是交给自适应平台更合适。
自适应平台就不一样了。它跑在应用处理器上，比如ARM Cortex-A系列。这类芯片性能强，能跑Linux或QNX。自适应平台主要服务自动驾驶、车载娱乐这些需要高算力的场景。
嗯，这里要注意：自适应平台不是经典平台的替代品，而是互补。一个管安全，一个管智能。两者通过SOME/IP或DDS通信，各司其职。
核心区别总结：
- 经典平台：硬实时、MCU、OSEK OS、CAN/LIN为主
- 自适应平台：软实时、AP处理器、POSIX OS、以太网为主
1.2 为什么汽车需要以太网？
这个问题，我经常被刚入行的朋友问。答案其实很简单：数据量上来了，老总线扛不住了。
你想想看，以前的车，一个ECU就管一个功能。车窗控制器只管车窗，雨刮器只管雨刮。CAN总线2.0A只有11位ID，带宽也就500kbps，够用。
但现在呢？一个摄像头每秒产生几百兆数据。激光雷达更夸张，点云数据动不动就上G。CAN总线那点带宽，连个高清视频流都传不了。以太网就不一样了，100BASE-T1就有100Mbps，1000BASE-T1直接上1Gbps。
我记得有一次调试ADAS系统，摄像头数据通过CAN传输，结果画面卡成PPT。后来换成以太网，流畅得跟本地播放一样。从那以后，我但凡遇到大数据量传输，第一反应就是“上以太网”。
还有一个原因：以太网生态成熟。TCP/IP协议栈、网络安全、远程诊断，这些在IT领域已经玩得很透了。汽车行业直接拿来用，省时省力。
个人建议：如果你刚开始做车载以太网，别急着啃协议栈源码。先搞清楚“为什么需要它”，比“怎么配置它”更重要。
1.3 车载网络演进：CAN/LIN → 以太网
车载网络的演进，说白了就是一场“带宽竞赛”。我把它分成三个阶段：
| 阶段 | 代表总线 | 带宽 | 典型应用 |
|---|---|---|---|
| 第一阶段 | LIN | 20 kbps | 车窗、座椅、门锁 |
| 第二阶段 | CAN / CAN FD | 500 kbps ~ 8 Mbps | 动力总成、车身控制 |
| 第三阶段 | 以太网 | 100 Mbps ~ 1 Gbps | ADAS、信息娱乐、OTA |
LIN总线，我最早接触的就是它。结构简单，成本低，但速度慢得可怜。20kbps什么概念？传一张1MB的图片，得花400秒。所以LIN只适合控制个车窗、调个座椅这种低速任务。
CAN总线，算是车载网络的“老兵”了。从1990年代用到现在，可靠性没得说。但CAN的带宽上限摆在那里，CAN FD虽然能到8Mbps，面对高清视频还是力不从心。
我曾经在一个项目里，用CAN FD传输雷达点云数据。结果发现，数据量稍微一大，总线就拥堵。后来没办法，只能降采样，牺牲了精度。嗯，这就是典型的“带宽不够，精度来凑”。
以太网的出现，彻底改变了局面。100BASE-T1只用一对双绞线，就能跑100Mbps。而且支持全双工，收发同时进行。更关键的是，以太网能承载SOME/IP、DDS、AVB/TSN这些高级协议。
避坑指南：我曾经以为以太网可以完全替代CAN。后来发现不行。以太网延迟不确定，硬实时场景还得靠CAN。所以现在的趋势是“混合网络”：CAN做控制，以太网做数据。
最后说一句：车载网络的演进，不是“谁取代谁”，而是“谁在什么场景下更合适”。你想想看，一个车窗控制器，用千兆以太网是不是有点大材小用？所以，选型要因地制宜。
好了，这一章就聊到这儿。下一章我们深入AUTOSAR以太网协议栈的架构，看看它到底是怎么分层、怎么工作的。