1. 从双域控这个词说起CCA架构到底在解决什么问题第一次看到华为CCA架构这个词的人大概率会愣一下——CCA是什么和MDC 610、MDC 810又是什么关系200 TOPS这个数字放在今天算高还是算低我当初接触这套平台的时候也是从一堆缩写开始啃的啃完之后发现如果先把它到底要解决什么问题想明白后面所有的参数和架构图都会变得顺理成章。CCA的全称是计算与通信架构Computing and Communication Architecture这是华为面向智能汽车场景提出的一套底层电子电气架构思路。传统汽车的电子电气架构是分布式的——一个功能一个ECU车窗一个、座椅一个、空调一个几十上百个控制器各管一摊线束长得吓人算力还分散。到了智能化阶段这种架构就撑不住了摄像头、激光雷达、毫米波雷达产生的数据量暴涨智驾算法需要的是集中式的、大算力的计算平台而不是一堆小控制器各自为战。CCA架构的核心思路就是把分散的算力收拢把通信的层级压平。它把整车分成几个大的域每个域里放一个高性能计算平台域内统一处理域间通过高速骨干网络通信。而MDCMobile Data Center移动数据中心就是华为在这个架构下拿出来的车规级计算平台产品线MDC 610和MDC 810是其中两个主力型号。那双域控又是什么简单说就是在一辆车上同时部署两个域控制器——通常是一个负责智能驾驶域一个负责智能座舱域或者两个域控做冗余备份。为什么要双域控原因有两个层面一是功能隔离智驾和座舱对安全等级、实时性、操作系统的要求完全不同混在一起做会互相干扰二是安全冗余L3及以上的自动驾驶要求系统在单点失效时仍能保证安全双域控可以互为备份。提示很多人把双域控理解成简单的两块板子其实关键不在硬件数量而在于两个域之间的任务划分、通信机制和失效切换策略。这部分设计得好不好直接决定了整套方案能不能落地。我个人的体会是理解CCA架构不要从硬件参数入手而要从数据流入手传感器数据从哪里进来、在哪里被处理、处理结果往哪里去、哪个环节可能成为瓶颈。把这条链路画清楚MDC 610和MDC 810的定位差异、200 TOPS算力的意义就全都清楚了。下面我就按这个思路把整套平台拆开来讲。2. MDC 610与MDC 810的定位差异不是简单的高低配很多人一看到两个型号第一反应是610是低配、810是高配。这个理解不算错但太粗糙了。实际上这两个平台在目标场景、算力配置、接口布局、散热方案上都有明确的分工选型的时候如果只盯着算力数字很容易选错。2.1 算力档位与目标场景的对应关系先看算力。MDC 610的算力大约在200 TOPS级别INT8MDC 810则要高出一大截通常在400 TOPS以上。这个差距不是随便定的而是对应着不同的智驾等级和传感器配置。平台型号典型算力INT8目标智驾等级典型传感器配置典型应用场景MDC 610约200 TOPSL2到L3多路摄像头毫米波雷达少量激光雷达高速领航、城区辅助驾驶MDC 810400 TOPS以上L3到L4多激光雷达高分辨率摄像头全向感知城区全场景、Robotaxi200 TOPS这个数字放在今天是什么水平做个类比早期L2级别的智驾平台算力普遍在个位数TOPS到几十TOPS200 TOPS相当于把算力提升了将近一个数量级。它足以支撑BEVTransformer这类主流感知算法在车端的实时推理也能跑得动中等规模的规划决策模型。但如果要上更复杂的多模态大模型、要做全场景的端到端200 TOPS就会吃紧这时候就得上810。2.2 接口布局算力之外的真正分水岭选型时比算力更容易被忽略的是接口。MDC 610和MDC 810在摄像头接入路数、激光雷达接口、CAN/FlexRay通道数、以太网带宽上都有差异。MDC 610通常支持十几路摄像头接入配合若干路CAN和车载以太网够L2场景用。MDC 810的摄像头接入能力更强能到二十路以上并且对高带宽激光雷达的原生支持更好。这一点很关键——激光雷达的点云数据量非常大如果平台的接口带宽不够要么降采样丢精度要么就得加额外的预处理芯片成本和复杂度都上去了。注意接口数量不是越多越好而是要和你的传感器方案匹配。我见过有人为了留余量选了接口更多的平台结果整车功耗和散热方案全都要重新设计反而拖慢了项目进度。选型的第一原则是够用且匹配不是堆料。2.3 散热与功耗车规落地的隐形门槛车规级平台和消费级芯片最大的区别之一就是工作温度范围。MDC系列要满足**-40℃到85℃**甚至更宽的温度要求这意味着散热设计不能照搬数据中心的思路。MDC 610的功耗相对可控通常采用被动散热风冷的组合就能压住。MDC 810算力高、功耗大往往需要液冷方案。这不是小事——液冷意味着整车要增加冷却回路、水泵、管路布置空间和成本都要重新算。很多项目在POC阶段用风冷跑通了一到量产装车就发现散热压不住被迫改方案这个坑非常常见。我的建议是在选型阶段就把散热方案和整车布置一起考虑不要等硬件定型了再补散热设计。尤其是MDC 810这种高功耗平台液冷回路的走向、接口位置、维护便利性都要提前和整车团队对齐。3. 200 TOPS算力是怎么用出来的从芯片到算法的全链路200 TOPS这个数字写在规格书上很漂亮但真正决定体验的不是这个峰值数字而是有效算力——也就是在实际算法负载下你能稳定跑出多少。我见过太多项目规格书上的算力很唬人实际跑起来因为内存带宽、调度效率、算子支持等问题有效算力打了对折。所以这一节我想重点讲讲这200 TOPS是怎么被用出来的。3.1 算力、内存带宽与算子支持的三角关系算力不是孤立的。一个AI加速器能不能跑满取决于三个条件同时满足计算单元够多、内存带宽够宽、算子支持够全。计算单元是工厂的机器数量内存带宽是原料进出的传送带速度算子支持是工厂能不能加工某种特殊材料。三者任何一个短板都会让整体效率掉下来。举个例子如果你的感知模型里有一个自定义算子平台的加速器不支持那这个算子就得回落到CPU上跑速度慢几十倍整个模型的推理时间就被它拖垮了。所以在评估MDC 610的200 TOPS时不能只看数字要问三个问题我的模型里有哪些算子平台的原生支持覆盖率是多少模型的内存访问模式是怎样的带宽会不会成为瓶颈多模型并行时调度策略能不能保证关键任务的实时性这三个问题问清楚了你才知道这200 TOPS对你来说到底能兑现多少。3.2 模型量化与INT8精度算力数字背后的前提规格书上的200 TOPS通常是INT8精度下的峰值。这意味着你的模型必须做量化——把训练时的FP32/FP16权重和激活值转成INT8才能跑到这个算力。量化做得好精度损失很小做得不好模型直接崩掉。量化的核心难点在于激活值的动态范围。权重是固定的量化相对好做但激活值随输入变化范围可能很宽直接线性量化会丢很多信息。常见的做法是逐通道量化加上校准集统计用一批有代表性的数据跑一遍统计每层激活值的分布再确定量化参数。提示量化校准集一定要用真实场景数据不能用随机数据或者训练集的子集随便凑。我踩过一次坑用训练集数据做校准结果模型在夜间场景下精度暴跌排查了很久才发现是校准集没有覆盖夜间分布。3.3 多模型并行的调度策略实际智驾系统里不是跑一个模型而是一堆模型同时跑感知、预测、规划、控制还有各种后处理。这些模型的实时性要求不同有的必须每帧都跑比如障碍物检测有的可以降频比如高精地图匹配。MDC平台的调度框架通常支持优先级调度和时间片分配。关键任务是硬实时必须保证在截止时间前完成非关键任务可以弹性调度。设计的时候要把任务按实时性分级给硬实时任务预留足够的算力余量。我一般的做法是先算总账再留余量。把所有任务的算力需求加起来如果接近200 TOPS的80%就要警惕了——实际运行时的抖动、峰值负载、温度降频都会吃掉余量。留20%到30%的余量是比较稳妥的。4. 双域控方案的落地细节任务划分、通信与失效切换前面讲了单平台的算力和选型这一节进入双域控的核心——两个域控怎么分工、怎么通信、怎么在出问题时切换。这部分是整套方案里最容易出问题、也最能体现设计功力的地方。4.1 任务划分按安全等级还是按功能模块双域控的任务划分有两种常见思路按安全等级划分和按功能模块划分。按安全等级划分就是把ASIL-D级别的功能比如AEB自动紧急制动放在一个域控ASIL-B级别的功能比如舒适性辅助放在另一个。这种划分的好处是安全隔离清晰坏处是同一个功能链路可能被拆到两个域通信开销大。按功能模块划分就是智驾一个域、座舱一个域或者感知一个域、规控一个域。这种划分实现简单但安全等级混在一起需要额外的隔离机制。实际项目中混合划分更常见先按功能模块分大块再在每个域内部按安全等级做隔离。比如智驾域里把AEB这类高安全等级的功能单独跑在一个隔离分区里和普通的感知任务隔开。划分方式优点缺点适用场景按安全等级隔离清晰认证容易通信开销大链路复杂高安全等级功能集中的场景按功能模块实现简单耦合低安全隔离需额外机制功能边界清晰的场景混合划分兼顾隔离与效率设计复杂度高大多数量产项目4.2 域间通信带宽、延迟与确定性两个域控之间的通信是双域控方案的命脉。通信设计要同时满足三个指标带宽够、延迟低、确定性好。带宽方面域间通常走车载以太网千兆甚至万兆。延迟方面要控制在毫秒级。但最容易被忽略的是确定性——也就是通信延迟的抖动要小。如果延迟忽高忽低上层的控制算法就没法做稳定的时序假设整个系统的行为会变得不可预测。保证确定性的常见手段是时间敏感网络TSN。TSN通过时间同步、流量整形、优先级调度等机制让关键数据的传输有可预测的延迟上界。在双域控方案里如果两个域之间有硬实时的数据交换比如冗余感知结果TSN几乎是必选项。注意TSN的配置不是开了就行需要根据实际流量做调度表设计。调度表设计不好关键流量的延迟反而会比不用TSN还差。这块建议用专业的网络规划工具来做手工配容易出错。4.3 失效切换从检测到到切过去要多久双域控的安全价值最终体现在失效切换上。当一个域控出问题另一个要能接管关键功能。这里的关键指标是切换时间——从故障检测到功能恢复总共花了多久。切换时间可以拆成三段故障检测时间 决策时间 接管执行时间。故障检测靠心跳、看门狗、ECC校验等机制决策是判断要不要切接管执行是把关键任务迁移到备用域并恢复运行。这三段里故障检测时间往往是大头。检测太灵敏会误报太迟钝会错过切换窗口。我的经验是根据功能的安全等级设定不同的检测阈值高安全等级功能用快速检测毫秒级低安全等级功能可以放宽几十毫秒级。接管执行时间取决于状态同步做得好不好。如果备用域一直在热备状态同步着主域的关键状态接管就快如果备用域是冷备接管时要重新初始化那就慢了。热备的代价是功耗和资源占用冷备的代价是切换慢这个权衡要根据具体功能来定。5. 实操中绕不开的几个坑从POC到量产的落差规格书和Demo跑通只是开始真正难的是从POC到量产。这一节我把自己和同行踩过的坑整理一下都是那种文档里不会写、但一定会遇到的问题。5.1 温度降频实验室跑得好好的一上车就掉算力这是最经典的坑。实验室环境25℃平台满负荷跑算力稳稳的。一装车夏天暴晒后车内温度60℃以上平台为了保护芯片开始降频算力直接掉30%甚至更多。如果你的算法没有留够余量这时候就会出问题——推理时间变长控制周期被打破功能降级。应对办法有两个一是散热设计留余量别按25℃的功耗来设计要按最高环境温度加满载来算二是算法层面做降级策略算力不够时优先保证关键功能非关键功能降频或暂停。5.2 电磁兼容车规认证的拦路虎车规认证里**电磁兼容EMC**是很容易翻车的一环。MDC这种高算力平台高速信号多、开关电源多电磁辐射本来就大。如果整车布置时没有做好屏蔽和滤波很容易超标。我见过一个项目POC阶段完全没考虑EMC量产前送测直接挂了被迫改PCB布局、加屏蔽罩、换连接器耽误了好几个月。EMC要在硬件设计阶段就介入别等送测了再补。5.3 软件生态与工具链的成熟度硬件平台再好软件工具链跟不上也白搭。MDC平台有自己的算子库、编译器、调试工具和主流的深度学习框架之间需要做模型转换。这个转换过程经常出问题算子不支持、精度对不齐、性能不达预期。我的建议是在选型阶段就把模型转换跑一遍别等硬件买了才发现模型跑不起来。拿你实际要用的模型走一遍完整的转换、量化、部署、验证流程看看精度损失多少、性能如何。这一步做扎实了后面能省很多事。提示模型转换时逐层对比输出是排查精度问题的有效手段。把原始模型和转换后模型每一层的输出都拿出来对比哪一层开始出现明显偏差问题就出在哪一层附近。6. 选型决策什么场景该上610什么场景该上810讲了这么多技术细节最后落到最实际的问题到底怎么选。我按几个典型场景给个参考。6.1 高速领航与城区辅助610的主场如果你的目标是高速领航辅助或者基础城区辅助驾驶传感器配置是多摄像头毫米波雷达可选激光雷达那MDC 610基本够用。200 TOPS的算力能支撑BEV感知和中等规模的规控模型接口数量也匹配这个级别的传感器方案。这个场景下选610的好处是功耗和散热压力小整车改动的成本低量产落地快。如果你的项目节奏紧、预算有限610是更务实的选择。6.2 城区全场景与高阶智驾810的必要性如果你的目标是城区全场景传感器里有多颗高分辨率激光雷达算法上要用端到端大模型或者复杂的多模态融合那810是必须的。400 TOPS以上的算力、更强的接口能力、液冷散热方案都是为这个级别的需求准备的。这个场景下不要试图用610硬扛。算力不够时你要么砍功能要么降频率用户体验会打折扣。与其后期痛苦地优化不如一开始就选对平台。6.3 双域控的冗余配置什么功能值得冗余最后说说双域控的冗余。不是所有功能都值得做冗余——冗余意味着双倍的成本和功耗。值得冗余的是安全关键功能AEB、车道保持、冗余制动等。这些功能一旦失效后果严重冗余是必要的。非安全关键功能比如娱乐、导航不需要冗余单域跑就行。把冗余资源集中在关键功能上是双域控方案设计的核心原则。场景推荐平台传感器配置冗余需求高速领航MDC 610多摄像头毫米波关键功能冗余城区辅助MDC 610/810摄像头雷达激光雷达关键功能冗余城区全场景MDC 810多激光雷达高分辨率摄像头全面冗余RobotaxiMDC 810双套全向感知全面冗余热备我在实际项目里的体会是选型这件事没有标准答案只有匹配度。同样的平台在不同的传感器方案、不同的算法负载、不同的整车约束下表现可能完全不同。所以别迷信规格书也别照搬别人的方案一定要拿自己的实际负载去测、去验证。测出来的数据比任何参数表都可靠。另外分享一个小技巧在做选型对比时除了算力和接口一定要把工具链成熟度和团队熟悉度纳入评估。一个团队用惯了的平台即使参数稍弱实际开发效率可能反而更高。硬件只是基础能把硬件用好的软件和人才是决定项目成败的关键。