第一章为什么90%的Camera项目，都死在第一步？

2026/7/6 13:46:22

第一章为什么90%的Camera项目，都死在第一步？

第一节一块返工300万元的PCB，让整个项目延期三个月

提问：
如果现在让你设计一块智能驾驶域控制器，你会先做什么？
大多数新人都会回答：
“先选SoC。”
有的人说：
“先选Camera。”
还有的人会说：
“先画原理图。”
这些答案都不算错。
但是在真正的Tier1公司，首席架构师通常先做一件完全不同的事情——算带宽。

📖 精讲（第一部分）

很多年轻工程师第一次接触智能驾驶项目时，总觉得摄像头只是一个普通外设。无非就是一颗CMOS、一个镜头，再通过GMSL或者FPD-Link把图像送到SoC，最后算法识别一下车道线和车辆，看起来整个流程并不复杂。

但是，当你真正参与一辆L2+甚至L3级智能汽车开发时，就会发现现实完全不是这样。

举个真实的工程例子。

某款城市NOA车型采用了3颗前视8MP摄像头、4颗环视2MP摄像头、4颗周视2MP摄像头以及1颗驾驶员监控摄像头。项目初期，大家认为每一路链路都满足芯片规格，实验室点亮测试也十分顺利，于是PCB很快进入试产。

然而进入整车联调后，问题开始出现。

高温暴晒两个小时以后，前视图像偶尔丢帧；连续跑高速时，环视画面会出现短暂卡顿；夜间HDR模式开启后，个别摄像头偶发重新建立链路。软件团队检查驱动没有发现异常，算法团队也确认模型正常，最终所有问题都指向硬件。

经过重新分析，真正的问题并不是Serializer，也不是Deserializer，更不是SoC性能不足，而是项目最开始计算Camera带宽时，只计算了图像有效数据，没有计算协议开销、同步信息、Blanking、ECC、CRC以及系统设计余量。

也就是说，第一步就算错了。

这个错误在实验室很难暴露，因为实验室环境稳定、线束较短、温度较低；但到了真实车辆环境，高温、振动、电磁干扰叠加以后，链路余量被迅速吃光，系统便开始暴露问题。

很多项目最后返工，并不是因为芯片选错，而是因为最开始没有把数据流量真正算明白。

🚗 工程案例：为什么实验室正常，上车却开始掉帧？

假设有一条高速公路，设计通行能力是每小时6000辆汽车。

平时你统计车流时，只计算了真正载货的大货车，却没有把公交车、小汽车、应急车辆以及收费站排队时间算进去。

于是你得出结论：

“6000辆肯定够跑。”

结果国庆节一到，高速立刻堵成停车场。

为什么？

因为真正占用道路资源的不只是货车。

Camera带宽也是一样。

很多工程师计算时，只算了：

图像像素 × 位宽 × 帧率

却忽略了：

视频同步包；
MIPI CSI-2包头；
ECC校验；
CRC校验；
Embedded Metadata；
Line Blanking；
Frame Blanking；
Virtual Channel信息；
Serializer编码开销；
Link Margin。

这些内容平时看不见，却一直在占用带宽。

所以实验室刚点亮时，链路利用率可能只有70%；到了整车环境，HDR、多摄同步、算法同时工作，链路利用率一下冲到95%以上，偶发错误自然开始出现。

真正成熟的硬件工程师，从来不会把链路设计到100%。

他们通常会预留20%~30%的带宽余量，因为汽车不是实验室，它需要在炎热、寒冷、颠簸、电磁干扰等各种环境下连续工作很多年。

🎓 总结

今天请大家先记住一句话：

Camera系统最大的敌人，从来不是分辨率，而是低估了数据量。

很多工程师工作几年以后，仍然认为：

Camera越高清，只是图片越大。

事实上，Camera送往域控制器的不是一张照片，而是一条持续不断、永不停歇的高速数据河流。

如果这条河流的流量一开始就计算错了，那么后面的Serializer、Deserializer、CSI-2、DDR、ISP、NPU都会像多米诺骨牌一样受到影响。

所以，Camera设计真正的起点不是画原理图，而是计算数据。

第二节为什么1080P叫2MP，而4K却叫8MP？

提问：
你每天都在说：
1080P。
2MP。
4K。
8MP。
但是有没有认真想过：
这些数字到底是怎么来的？
下一节，我们不急着写任何公式，而是先把**“像素”**这块最基础、也是最容易被忽略的积木彻底讲透。

下一节开始，我们会进入一步一步推导：

为什么1080P叫2MP？为什么8MP不是8MB？为什么RAW12不是12Byte？

第一章为什么90%的Camera项目，都死在第一步？