1、车载网络概述
各位同学，今天咱们来聊聊车载网络。说实话，我刚入行那会儿，车里的电子系统还没这么复杂。一辆车能有几十个ECU就算高端了。现在呢？动辄上百个，没有一套靠谱的网络，根本玩不转。
我个人习惯把车载网络比作车的神经系统。传感器是末梢神经，ECU是神经中枢，而网络就是连接它们的脊髓和神经纤维。没有它，车就是个铁疙瘩。
1.1 车载网络的发展历程
最早的车载网络，其实没什么网络可言。我记得上世纪80年代，车里的电子设备都是点对点连接。一个开关控制一个灯，一根线连一个传感器。简单粗暴，但线束多得吓人。
为什么会这样？因为那时候的ECU功能单一，不需要互相通信。但随着排放法规越来越严，发动机、变速箱、ABS这些系统必须协同工作。线束越来越重，成本越来越高，工程师们坐不住了。
于是，CAN总线在1986年被提了出来。这玩意儿真是革命性的。一根双绞线，就能让所有ECU互相聊天。我在一个老项目中见过早期的CAN实现，那布线清爽得让人感动。
后来，随着车身舒适性、信息娱乐、安全驾驶的需求爆发，各种协议纷纷登场。LIN负责低成本的门窗控制，FlexRay扛起了线控底盘的重任，MOST搞定了多媒体传输。到了今天，以太网一脚踹开了车载网络的大门，带宽直接上Gbps。
嗯，这里要注意，不是新协议取代旧协议，而是共存。一辆现代汽车里，CAN、LIN、FlexRay、以太网各司其职，这才是常态。
1.2 主要车载网络协议简介
下面我把几个主流协议挨个儿捋一遍。每个协议都有它的脾气，选错了可是要吃苦头的。
1.2.1 CAN（控制器局域网）
CAN是车载网络的元老，也是目前应用最广的。它采用差分信号传输，抗干扰能力强。我在项目中遇到过，CAN总线在发动机舱这种电磁环境恶劣的地方，依然稳如老狗。
CAN的速率最高1Mbps，对于动力总成、底盘控制这些实时性要求高的场景，刚刚好。它的仲裁机制很有意思——谁优先级高谁先说话，低优先级的自动退让。这设计，说白了就是让重要数据永远不堵车。
关键特点：
- 多主总线，任意节点可发起通信
- 非破坏性逐位仲裁
- 错误检测与自动重发
- 最大节点数受总线负载限制，通常不超过110个
1.2.2 LIN（局域互联网络）
LIN是CAN的小弟，成本低、速率慢（最高20kbps）。它主要用于车门、车窗、座椅、天窗这些对实时性要求不高的地方。
LIN采用主从架构，一个主节点带多个从节点。我曾经在一个项目中用LIN控制后视镜折叠，成本比CAN方案省了将近一半。但要注意，LIN的从节点不能主动发数据，只能等主节点问。所以，别指望它做实时控制。
1.2.3 FlexRay
FlexRay是冲着高可靠性和确定性来的。速率最高10Mbps，支持双通道冗余，时间触发机制让数据传输的抖动极小。
我记得有个线控转向的项目，要求转向指令的延迟必须小于1毫秒，抖动不超过50微秒。CAN做不到，以太网当时还不成熟，最后选了FlexRay。说实话，FlexRay的配置确实复杂，但它的确定性是其他协议比不了的。
个人建议：如果你的系统需要硬实时、高可靠性，比如线控制动、线控转向，FlexRay是首选。但要做好心理准备，它的开发工具和调试手段比CAN贵不少。
1.2.4 MOST（面向媒体的系统传输）
MOST是专门为多媒体设计的。它用光纤传输，带宽最高150Mbps，抗干扰能力极强。早期的车载娱乐系统、导航系统，很多都用MOST。
不过，随着以太网AVB/TSN的成熟，MOST的地位越来越尴尬。我最近几年参与的项目，新平台基本都转向以太网了。MOST的生态太封闭，授权费也不便宜，被淘汰是迟早的事。
1.2.5 车载以太网
以太网是车载网络的未来。100BASE-T1、1000BASE-T1这些标准，专门针对汽车环境做了优化。单对非屏蔽双绞线，就能跑100Mbps甚至1Gbps。
为什么以太网这么香？因为它能复用IT领域成熟的技术栈。TCP/IP、HTTP、SOME/IP、DDS，这些协议可以直接拿来用。我在一个ADAS项目中，用以太网传输摄像头原始数据，带宽完全不是问题。
但以太网也有坑。它的实时性不如FlexRay，需要靠TSN（时间敏感网络）来弥补。另外，以太网的物理层芯片功耗比CAN高，散热是个问题。
| 协议 | 速率 | 拓扑 | 主要应用 |
|---|---|---|---|
| CAN | 最高1Mbps | 总线型 | 动力总成、底盘、车身控制 |
| LIN | 最高20kbps | 主从型 | 车门、车窗、座椅 |
| FlexRay | 最高10Mbps | 星型/总线型 | 线控系统、安全关键应用 |
| MOST | 最高150Mbps | 环形 | 信息娱乐、多媒体 |
| 以太网 | 100Mbps~1Gbps | 星型 | ADAS、诊断、OTA、域控互联 |
1.3 车载网络的分层架构
你想想看，这么多协议混在一起，怎么管理？答案是分层。车载网络的分层架构，说白了就是把通信功能拆成几层，每层各司其职。
最经典的是OSI七层模型，但在车载领域，我们通常简化成三层：
- 物理层：负责信号的传输。比如CAN的差分电平、以太网的PAM3编码。这一层决定了速率、距离、抗干扰能力。
- 数据链路层：负责帧的封装、寻址、错误检测。CAN的ID仲裁、以太网的MAC地址，都在这一层。
- 应用层：负责具体的业务逻辑。比如诊断协议UDS、网络管理协议NM、服务发现协议SOME/IP。
我个人习惯把中间再加一层——传输层。虽然OSI模型里有，但车载网络早期不太重视。现在以太网进来了，TCP/UDP、AVB、TSN这些传输层协议越来越重要。
注意：不同协议的分层粒度不一样。CAN的协议栈只覆盖物理层和数据链路层，应用层需要自己定义。而以太网从物理层到应用层都有成熟标准。选型时一定要搞清楚，别指望CAN能直接跑HTTP。
举个例子，我在一个项目中需要把CAN数据通过以太网上传到云端。CAN的数据链路层只负责把报文发出去，应用层得自己写。我封装了一个CAN-to-Ethernet网关，在应用层把CAN ID映射成以太网的Topic，再用MQTT发到云端。说白了，就是手工搭桥。
嗯，这里要强调一下，分层架构的好处是解耦。物理层换了，应用层不用改。数据链路层升级了，上层协议照样跑。我在做平台化设计时，最看重的就是这一点。
好了，第一章就聊到这儿。车载网络的基础框架搭起来了，后面咱们再深入每个协议的QoS保障细节。下一章，我会重点讲CAN的优先级仲裁和实时性保障，那可是个硬骨头。