第一讲：车载存储概述

为什么车载需要专用存储？

说实话，我刚开始做车载系统那会儿，也想过这个问题——手机用的eMMC、电脑用的SSD，不都是存储吗？为什么非得搞个「车载专用」？

后来踩了几个坑，才明白其中的门道。

车载存储和消费电子存储，本质上是两个物种。你想想看，手机坏了最多换个手机，车机存储坏了呢？轻则黑屏重启，重则影响行车安全。我有个朋友在某Tier1做售后，他说遇到过一台车，因为存储芯片老化导致360影像卡死，车主倒车时撞了柱子——这种事故，消费电子领域根本不会发生。

车载存储的特殊性，主要体现在三个方面：

• 温度范围：消费级存储一般0℃~70℃，车规级要-40℃~105℃。我在夏天做过路试，车内仪表盘温度能到85℃，普通SD卡直接罢工。
• 寿命要求：手机用2-3年换，车要用10-15年。而且车机每天启动多次，读写模式完全不同。
• 可靠性：车规级存储必须通过AEC-Q100认证，这是硬门槛。我见过不少方案因为没通过认证，最后被迫换料重做。

车载存储的演进历史

车载存储的发展，说白了就是一部「容量越来越大、速度越来越快、可靠性越来越高」的历史。我把它分成三个阶段来讲。

第一阶段：SD卡时代（2005-2012）

早期车载娱乐系统，导航地图、音乐文件都存在SD卡里。那时候的车机功能简单，存储需求也就几百MB到几个GB。

但SD卡的问题很明显：

• 接触不良：车辆震动会导致卡座松动，我遇到过导航走到一半突然「请插入SD卡」的尴尬
• 速度慢：Class 10的卡写入也就10MB/s，加载地图要等半天
• 寿命短：频繁读写容易坏，尤其是山寨卡

我记得2010年做的一个项目，客户坚持用SD卡方案，结果量产半年后返修率高达8%。后来全部换成eMMC，返修率降到0.5%以下。这个教训让我明白——车载存储，焊接式才是正道。

第二阶段：eMMC时代（2012-2020）

eMMC的出现，解决了SD卡的几个痛点：

• 焊接在板子上，不怕震动
• 内置Flash控制器，管理磨损均衡
• 容量从4GB到128GB，满足导航+娱乐需求

eMMC的接口标准从4.4发展到5.1，速度从50MB/s提升到400MB/s。说实话，对于大部分车机应用，eMMC 5.1已经够用了。

但有个坑：eMMC的寿命取决于写入量。我曾经遇到一个项目，车机频繁写日志，结果eMMC两年就挂了。后来加了日志轮转策略，才把寿命延长到10年以上。

第三阶段：UFS时代（2020至今）

UFS（Universal Flash Storage）是当前车载存储的主流方案。它和eMMC最大的区别是：

对比项	eMMC	UFS
接口	半双工（8位并行）	全双工（2通道串行）
速度	最高400MB/s	最高2900MB/s（UFS 3.1）
命令队列	不支持	支持（最多32个命令）
功耗	较高	更低

UFS的优势很明显：速度快、延迟低、支持多任务并发。对于现在的智能座舱——多屏互动、语音识别、高精地图加载——UFS几乎是必须的。

我个人习惯：新项目优先选UFS 2.1或3.1。如果成本敏感，eMMC 5.1也能用，但要严格控制写入量。

嗯，这里要注意一点：UFS虽然好，但驱动复杂度比eMMC高不少。Linux内核从4.13开始才原生支持UFS，如果你的BSP版本比较老，可能需要打补丁。

小结

车载存储的演进，本质上是「可靠性」和「性能」的平衡。SD卡时代我们追求「能用」，eMMC时代追求「可靠」，UFS时代追求「高效」。

下一讲，我会深入分析eMMC和UFS的底层架构差异，以及如何根据项目需求做选型。如果你正在纠结「到底用eMMC还是UFS」，那节课应该能帮到你。