3、车载网络流量特征：数据流分类与QoS需求
聊到车载网络的QoS保障，咱们得先搞清楚一个问题：车上到底跑着哪些数据流？
说实话，我刚开始接触车载网络那会儿，觉得不就是些传感器信号嘛，能有多复杂？后来真正做项目才发现——车载网络里的数据流，简直是个大杂烩。不同类型的流量，对延迟、带宽、可靠性的要求天差地别。你想想看，刹车信号和娱乐视频能一样对待吗？
3.1 车载网络中的数据流分类
根据我的项目经验，车载数据流大致可以分为四类。嗯，这里我按优先级从高到低排个序：
3.1.1 控制流
这是车上最要命的数据流。包括转向、制动、油门、换挡等实时控制信号。我在做线控底盘项目时，亲眼见过控制流延迟超过10ms导致的车身抖动——那感觉，就像有人在你开车时突然抢方向盘。
- 典型信号：方向盘转角、轮速、制动压力
- 周期特性：通常为1ms~10ms的固定周期
- 数据量：单个信号通常只有几个字节
- 致命要求：延迟必须<10ms，最好<5ms
3.1.2 信息流
这类数据流负责传递车辆状态信息，比如车速、水温、油量、胎压等。它不像控制流那么紧急，但可靠性要求很高——你总不希望仪表盘上显示的车速忽高忽低吧？
- 典型信号：车速、发动机转速、续航里程
- 周期特性：100ms~1s的周期性广播
- 数据量：每个信号2~8字节
- 特点：允许少量丢包，但不能连续丢
我个人习惯把信息流比作"仪表盘的血液"——它不需要跑得最快，但必须持续稳定地供应。
3.1.3 诊断流
诊断流是给维修人员和工程师用的。包括UDS诊断请求/响应、DTC故障码、ECU刷写数据等。这类流量平时不怎么出现，但一旦出现，数据量可能很大。
- 典型场景：OBD诊断、OTA升级、ECU刷写
- 触发方式：事件触发，非周期性
- 数据量：刷写时可达几MB甚至几十MB
- 特殊要求：不能影响控制流，但自身需要高可靠性
3.1.4 多媒体流
这个大家最熟悉——车载娱乐系统的数据流。包括音频、视频、导航地图、手机投屏等。它的特点是带宽需求大，但对延迟和可靠性要求相对宽松。
- 典型信号：USB音频流、蓝牙电话、视频流
- 带宽需求：音频几十kbps，视频可达几十Mbps
- 延迟容忍：音频<50ms，视频<200ms
- 特点：允许偶尔卡顿，但不能频繁断流
3.2 不同数据流的QoS需求差异
你看，这四类流量的需求差异有多大？我整理了一张表，方便你对比：
| 流量类型 | 延迟要求 | 带宽需求 | 可靠性要求 | 典型优先级 |
|---|---|---|---|---|
| 控制流 | <5ms（硬实时） | 低（kbps级） | 极高（零丢包） | 最高（0~1） |
| 信息流 | 100ms~1s | 低（kbps级） | 高（允许少量丢包） | 中高（2~3） |
| 诊断流 | 100ms~1s（非实时） | 中（Mbps级） | 极高（必须完整传输） | 中低（4~5） |
| 多媒体流 | 50~200ms | 高（Mbps~Gbps级） | 中（允许丢包重传） | 最低（6~7） |
为什么会这样？说白了，控制流关乎生命安全，多媒体流关乎用户体验。你想想看，导航卡顿一下顶多走错路，但刹车延迟10ms可能就是一场事故。
3.3 流量模型与建模方法
搞清楚了流量分类，下一步就是怎么建模。我在做网络设计时，通常用三种模型来描述车载流量：
3.3.1 周期模型
这是最常用的模型。控制流和信息流基本都是周期性的。比如一个轮速传感器，每10ms发一次数据，雷打不动。
// 周期流量模型示例（伪代码）
struct PeriodicFlow {
uint32_t period_ms; // 周期，单位ms
uint32_t message_size; // 报文大小，单位字节
uint8_t priority; // 优先级
uint32_t jitter_tolerance; // 允许的抖动，单位us
};
// 典型配置：制动控制流
PeriodicFlow brake_flow = {
.period_ms = 5, // 5ms周期
.message_size = 8, // 8字节
.priority = 0, // 最高优先级
.jitter_tolerance = 100 // 允许100us抖动
};3.3.2 事件触发模型
诊断流和部分告警信号属于这类。平时不出现，但一来就是一大波。我记得有一次做OTA刷写测试，诊断流瞬间把CAN总线占满了——还好我提前做了带宽预留。
// 事件触发流量模型
struct EventFlow {
uint32_t burst_size; // 突发数据量，单位字节
uint32_t max_rate; // 最大速率，单位bps
uint32_t min_interval; // 最小间隔，单位ms
bool is_critical; // 是否影响安全
};
// 典型配置：UDS诊断请求
EventFlow diag_flow = {
.burst_size = 4096, // 4KB突发
.max_rate = 500000, // 500kbps
.min_interval = 10, // 10ms最小间隔
.is_critical = false // 非安全关键
};3.3.3 流媒体模型
多媒体流通常用令牌桶模型来描述。它允许短时间内的突发，但长期平均速率受限制。
// 流媒体流量模型（令牌桶）
struct StreamingFlow {
uint32_t avg_rate; // 平均速率，单位bps
uint32_t peak_rate; // 峰值速率，单位bps
uint32_t bucket_size; // 令牌桶容量，单位字节
uint32_t latency_budget; // 延迟预算，单位ms
};
// 典型配置：1080p视频流
StreamingFlow video_flow = {
.avg_rate = 15000000, // 15Mbps平均
.peak_rate = 30000000, // 30Mbps峰值
.bucket_size = 65536, // 64KB令牌桶
.latency_budget = 100 // 100ms延迟预算
};3.4 我的建模经验总结
最后，分享几个我在项目中总结的建模原则：
- 先分类，后建模——搞清楚每类流量的特性再动手
- 留余量——实际流量往往比模型预测的多20%~30%
- 考虑最坏情况——比如所有诊断请求同时触发时，网络能否扛住
- 验证模型——用实际测试数据反哺模型，不断迭代
嗯，这一章的内容就到这里。下一章我们会聊QoS机制的具体实现——包括优先级调度、流量整形、带宽预留这些硬核技术。到时候我会结合CAN FD和车载以太网的实际案例来讲，敬请期待。