企业官网建设流程全解析

1. 从CCA架构说起：华为为什么要做“计算与通信”的融合平台

我第一次接触华为CCA架构是在一个智能驾驶域控选型的项目里，当时团队在讨论到底用传统分布式ECU方案还是上集中式域控，有人甩出了一份MDC 610和MDC 810的对比资料，里面反复提到一个词——CCA。后来花了不少时间把这条技术线捋清楚，才发现它不只是一个硬件平台的命名，而是华为在智能汽车计算平台上的一整套设计哲学。

CCA全称是Computing and Communication Architecture，直译过来就是“计算与通信架构”。这个名字本身就点明了它的核心思路：把“算”和“连”这两件事从底层就绑在一起设计，而不是先做一块算力板，再外挂几个通信模块。传统做法里，计算平台和通信网络往往是两拨人分别设计的，算力板负责跑算法，网关负责转发数据，中间靠一堆线束和协议对接。这种模式在分布式ECU时代还能凑合，但到了L3以上的智能驾驶场景，传感器数量暴增、数据带宽需求飙升，算力和通信割裂带来的延迟、带宽瓶颈、同步问题就会集中爆发。

华为CCA架构要解决的就是这个矛盾。它把计算单元、通信单元、供电、散热、安全模块在架构层面统一规划，形成一个“硬件平台+软件框架+工具链”的完整底座。MDC 610和MDC 810就是基于CCA架构落地的两款代表性域控制器产品，前者面向中低算力场景，后者面向高算力场景，两者可以组成“双域控”方案，覆盖从L2+到L4的智能驾驶需求。

这里有个关键点需要说清楚：CCA架构不是单纯堆算力，而是强调“算力效率”。什么意思？同样标称200 TOPS的平台，有的方案实际跑起来只能发挥出60%的算力，因为数据搬运、内存带宽、任务调度拖了后腿。CCA架构通过计算与通信的协同设计，让算力能更高效地转化为实际推理性能。这也是为什么华为在宣传MDC平台时，总喜欢强调“有效算力”而不是“峰值算力”。

适合谁来参考这篇内容？如果你是做智能驾驶域控选型的系统工程师、负责自动驾驶软件部署的算法工程师，或者是对车载计算平台感兴趣的技术管理者，这篇内容应该能帮你把MDC 610/810和CCA架构的关系、双域控方案的设计逻辑、200 TOPS算力的实现路径理清楚。我会尽量用实际项目中的视角来讲，而不是照搬产品手册。

2. MDC 610与MDC 810的核心差异：不只是算力数字的区别

2.1 算力配置与芯片架构解析

MDC 610和MDC 810最直观的差异当然是算力。MDC 610的典型配置在48 TOPS到100 TOPS之间（根据具体版本和散热条件有浮动），而MDC 810可以做到200 TOPS以上，部分高配版本甚至能到400 TOPS。但这个数字背后，芯片架构的差异才是真正决定适用场景的因素。

MDC 610通常搭载的是华为自研的昇腾310系列AI芯片，采用达芬奇架构，主打能效比。它的设计思路是“够用就好”，面向的是L2+到L3级别的智能驾驶功能，比如高速领航辅助、自动泊车、城区拥堵跟车这些场景。这些场景的特点是：传感器数量相对可控（比如5个摄像头+3个毫米波雷达+12个超声波雷达），算法模型以中等规模的CNN和部分Transformer为主，对算力的需求不是无底洞，但对功耗和成本非常敏感。

MDC 810则搭载昇腾610芯片，算力密度大幅提升。它的目标场景是L3到L4，传感器配置可能是11个摄像头+5个毫米波雷达+3个激光雷达，数据吞吐量是MDC 610的数倍。昇腾610在架构上做了几件关键的事：一是增加了矩阵计算单元的数量和位宽，二是优化了片上缓存和内存带宽，三是强化了多芯片互联能力。这些改动让MDC 810在处理大规模点云、多路高分辨率视频流、复杂BEV+Transformer模型时，能保持较低的延迟。

我整理了一个对比表格，方便你快速看清两者的定位差异：

这个表格里的数字不是绝对的，因为华为给OEM厂商的是一套可配置的方案，具体参数会根据车型的散热条件、传感器配置、功能定义做调整。但大致的定位区间是清晰的。

2.2 接口与扩展能力对比

接口这块是很多人在选型时容易忽略的地方，但实际项目中它往往决定了一个平台能不能“撑到”车型生命周期结束。MDC 610的接口配置相对精简：通常有4-8路摄像头输入（GMSL或FPD-Link）、4路CAN/CAN-FD、1-2路千兆以太网、若干路LIN和FlexRay。这个配置对于L2+场景是够用的，但如果你后续想加激光雷达或者升级到更高分辨率的摄像头，接口数量可能就会成为瓶颈。

MDC 810在接口上明显更“富裕”：摄像头输入可以做到12-16路，以太网接口支持万兆级别，CAN/CAN-FD通道数量翻倍，还预留了PCIe扩展槽用于加装额外的加速卡或存储模块。更重要的是，MDC 810支持多芯片级联，两颗昇腾610可以通过高速互联总线组成一个更大的计算池，算力叠加的同时保持内存一致性。这个特性在双域控方案里非常关键，后面会详细讲。

注意：接口数量不是越多越好，每增加一路高速接口，PCB布线难度、EMC风险、散热压力都会上升。选型时要根据“当前功能需求+未来2年OTA规划”来定，不要为了“留余量”而过度设计，否则成本和开发周期都会失控。

2.3 软件栈与工具链的兼容性

MDC 610和MDC 810在软件层面是高度兼容的，都跑华为的MDC软件平台，支持AUTOSAR Adaptive、ROS2、以及华为自研的MindSpore推理框架。这意味着如果你先在MDC 610上开发了算法，后续迁移到MDC 810时，大部分代码不需要重写，只需要针对算力提升做模型量化和并行化优化。

但这里有个坑：MDC 610和MDC 810的算子库版本可能不同。昇腾310和昇腾610支持的算子集有差异，某些在310上能高效运行的算子，在610上可能需要替换成等效实现。我遇到过的情况是，一个基于Depthwise Convolution的轻量级分割模型在MDC 610上跑得很好，迁移到MDC 810后反而变慢了，原因是610的硬件架构对Depthwise算子的优化不如310激进。后来换成普通Convolution加通道剪枝，性能才恢复正常。

所以，如果你打算用双域控方案，软件团队需要提前做算子兼容性测试，不能假设“高算力平台一定能跑得更快”。

3. 双域控方案的设计逻辑：为什么要用两个域控而不是一个

3.1 单域控方案的瓶颈在哪里

在讨论双域控之前，先说说为什么单域控方案在某些场景下不够用。一个MDC 810理论上可以搞定L3级别的所有功能，但实际项目中会遇到几个问题：

第一是功能安全隔离。智能驾驶系统里，不同功能的安全等级要求不同。比如自动紧急制动（AEB）要求ASIL-D，而舒适性跟车功能可能只需要ASIL-B。如果所有功能跑在同一个域控上，一旦高安全等级的功能出现故障，可能会影响低安全等级功能的运行，反之亦然。虽然可以通过Hypervisor做虚拟机隔离，但硬件层面的隔离更彻底。

第二是散热和功耗的物理限制。MDC 810满载功耗可以到300W，如果再加上传感器融合、规划控制、座舱交互等所有任务，功耗和发热会非常可观。单域控方案需要更复杂的散热设计，而双域控可以把负载分散，每个域控的散热压力更小。

第三是OTA升级的灵活性。双域控方案可以做到“一个域控升级，另一个域控继续运行”，实现不停车升级。单域控方案在升级时通常需要停车等待，用户体验会打折扣。

3.2 双域控的典型分工模式

华为MDC 610/810双域控方案常见的分工模式有两种：

模式一：按功能安全等级分工。MDC 810负责高安全等级的核心驾驶功能（AEB、车道保持、自适应巡航），MDC 610负责舒适性功能和座舱交互（导航、娱乐、语音助手）。两个域控之间通过高速以太网交换必要的数据，比如MDC 610把导航目的地的路径信息发给MDC 810，MDC 810把车辆状态和感知结果发给MDC 610用于显示。

模式二：按传感器域分工。MDC 810处理前向主摄像头、激光雷达、前向毫米波雷达的数据，负责前向感知和决策；MDC 610处理侧后向摄像头、超声波雷达的数据，负责泊车、盲区监测、变道辅助。这种分工模式下，两个域控各自有独立的感知 pipeline，最后在决策层做融合。

我参与过的一个项目用的是模式一，实际跑下来发现几个经验点：两个域控之间的数据同步非常关键，如果时间戳对不齐，融合结果会出现“鬼影”或者目标跳变。我们当时的做法是用PTP（精确时间协议）做时钟同步，同步精度控制在1毫秒以内，同时在应用层做时间戳对齐和插值补偿。

3.3 双域控的通信与同步机制

双域控之间的通信通常走千兆或万兆以太网，协议上可以用SOME/IP、DDS或者华为自研的通信中间件。选择哪种协议取决于你的软件架构：如果用的是AUTOSAR Adaptive，SOME/IP是自然选择；如果用的是ROS2，DDS更顺手。

同步机制方面，除了前面提到的PTP时钟同步，还需要考虑数据缓冲和丢包处理。以太网通信在车载环境下可能受到电磁干扰，出现偶发丢包。我们的做法是在应用层加一个滑动窗口缓冲，收到乱序或延迟的数据包时先缓存，等齐了再处理。窗口大小根据实际网络抖动情况调整，一般设50-100毫秒。

提示：双域控方案的通信带宽规划要留足余量。我们当时按峰值数据量的1.5倍来设计带宽，实际跑下来在极端场景（比如隧道内多目标+强电磁干扰）下，网络利用率会冲到80%以上，如果没有余量就会出现延迟飙升。

4. 200 TOPS算力的实现路径：从芯片到系统的全链路优化

4.1 昇腾610的算力构成

200 TOPS这个数字是怎么来的？昇腾610芯片内部有多个计算核心，包括矩阵计算单元、向量计算单元、标量计算单元。TOPS（Tera Operations Per Second）通常指的是INT8精度下的理论峰值算力。昇腾610在INT8下的峰值算力可以到200 TOPS以上，但这是理论值，实际能跑出多少取决于模型结构、内存带宽、任务调度等多个因素。

我实测过几个典型模型在MDC 810上的表现：ResNet-50在INT8下可以跑到每秒数千帧，YOLOv5s可以跑到几百帧，BEV+Transformer模型（比如BEVFormer的简化版）可以跑到30-50帧。这些数字和理论峰值有差距，但考虑到车载场景对延迟和功耗的约束，这个表现已经相当不错了。

4.2 算力效率的关键影响因素

内存带宽是第一个瓶颈。昇腾610的片上缓存有限，大部分模型参数和中间激活值需要存在DDR里。如果模型的内存访问模式不友好，比如频繁的随机访问或者大跨度的卷积，内存带宽就会成为瓶颈，算力利用率可能掉到30%以下。优化方法是做内存布局优化，把卷积的输入输出按NHWC格式排列，减少跨通道访问。

算子融合是第二个关键。昇腾610支持算子融合，可以把Conv+BN+ReLU这样的组合融合成一个算子，减少中间结果的写回和读取。我们在部署一个分割模型时，通过算子融合把推理延迟从45毫秒降到了28毫秒，效果非常明显。

多核并行是第三个手段。昇腾610有多个AI Core，可以把一个大模型的不同层分配到不同核心上并行计算，也可以把多个小模型分配到不同核心上同时推理。但并行不是免费的，核心之间的数据同步和任务调度有开销。我们的经验是，当模型的计算量足够大（比如单层计算超过1毫秒）时，并行收益才明显；小模型并行反而可能变慢。

4.3 从芯片算力到系统算力的转化

200 TOPS是芯片的算力，但系统层面的有效算力还要打折扣。折扣来自几个方面：一是散热限制，如果温度过高，芯片会降频，算力直接下降；二是供电限制，瞬态大电流可能导致电压跌落，触发保护；三是软件开销，操作系统、通信中间件、安全监控都会占用一部分CPU和内存资源。

我们在一个项目里做过测试：MDC 810在25度室温、液冷正常工作的条件下，持续跑满载推理任务，芯片温度稳定在65度左右，算力输出稳定在标称值的85%以上。但在45度高温环境下，如果散热系统不给力，温度冲到85度以上，算力会掉到60%以下。所以，散热设计不是“配角”，它直接决定你能不能用满200 TOPS。

5. 实操落地：MDC 610/810双域控方案的部署要点

5.1 硬件集成与散热设计

硬件集成阶段最容易出问题的是散热和供电。MDC 810的功耗高，如果用车载风冷，需要保证风道设计合理，进风口不能有遮挡，出风口的熱空气不能回流。我们当时用红外热像仪扫过一遍，发现靠近出风口的线束温度比预期高15度，后来加了隔热套管才解决。

供电方面，MDC 810的瞬态电流可能达到几十安培，电源线径要足够粗，接插件要选车规级的高电流型号。我们踩过的坑是：一开始用了普通接插件，结果在低温启动时出现接触电阻过大，导致域控反复重启。换成镀金车规接插件后问题消失。

液冷方案的话，冷却液的流量和温度要匹配域控的发热量。一个经验公式是：每100W功耗需要至少0.5L/min的冷却液流量，冷却液入口温度建议控制在25-35度之间。如果入口温度过高，芯片结温会逼近上限，触发降频。

5.2 软件部署与算力分配

软件部署的第一步是确定哪些任务跑在MDC 810上，哪些跑在MDC 610上。我们的原则是：安全关键、延迟敏感的任务放810，舒适性、非实时任务放610。具体来说，AEB、LKA、ACC的感知和决策跑在810上，导航渲染、语音交互、OTA管理跑在610上。

算力分配要用工具来量化，不能拍脑袋。华为的MDC工具链里有算力评估工具，可以输入模型结构，估算在目标芯片上的算力占用和延迟。我们当时把每个模型的算力需求列出来，加总后发现810的算力占用到了75%，610到了60%，留了25%-40%的余量给后续OTA。这个余量是必要的，因为新功能往往会增加算力需求。

注意：算力分配不是一劳永逸的。每次OTA增加新功能后，都要重新评估算力占用。我们遇到过OTA后某个模型版本更新，算力占用突然增加了20%，导致810的余量被吃光，后来不得不把部分非关键任务迁移到610上。

5.3 通信中间件配置与调优

双域控之间的通信中间件配置直接影响系统延迟和稳定性。我们用的是DDS，配置了几个关键参数：一是QoS策略，可靠性设为RELIABLE，确保关键数据不丢；二是历史深度，设为10，允许缓存最近10个数据包；三是心跳间隔，设为100毫秒，用于检测通信链路是否正常。

调优过程中发现，DDS的默认配置在车载网络环境下不够用。默认的发送缓冲区太小，高带宽数据（比如点云）发送时会丢包。后来把发送缓冲区从64KB调到1MB，丢包问题解决。另外，DDS的发现协议在系统启动时会广播大量数据，如果两个域控同时启动，网络会短暂拥塞。我们的做法是让610延迟5秒启动，错开发现阶段。

6. 常见问题与排查技巧实录

6.1 算力不达预期的排查思路

问题现象：MDC 810上跑一个标称需要100 TOPS的模型，实际推理延迟比预期高出一倍。

排查步骤：

1. 先用华为的profiling工具看算力利用率，如果低于50%，说明瓶颈不在算力本身。
2. 检查内存带宽占用，如果接近峰值，说明是内存瓶颈。优化方法是做算子融合和内存布局调整。
3. 检查芯片温度，如果超过80度，说明在降频。改善散热后重新测试。
4. 检查是否有其他任务在抢占AI Core资源。用资源隔离工具把关键任务绑定到专用核心上。

我们当时遇到的情况是内存带宽瓶颈，优化后算力利用率从45%提升到了78%，延迟降到了预期范围内。

6.2 双域控通信延迟过高的处理

问题现象：MDC 610和MDC 810之间的数据同步延迟超过10毫秒，导致融合感知出现目标跳变。

排查步骤：

1. 用网络抓包工具看两个域控之间的实际通信延迟。如果网络延迟本身很低（比如1毫秒），问题出在应用层。
2. 检查应用层的时间戳对齐逻辑。如果两个域控的时钟不同步，时间戳会对不齐。用PTP同步时钟，精度控制在1毫秒以内。
3. 检查数据缓冲窗口大小。如果窗口太小，乱序数据包会被丢弃；如果太大，延迟会增加。根据实际网络抖动调整窗口大小。

我们的问题是时钟同步精度不够，PTP配置有误。修正后延迟降到了3毫秒以内，目标跳变消失。

6.3 常见问题速查表

6.4 独家避坑技巧

技巧一：提前做算子兼容性矩阵。如果你打算在610和810之间迁移模型，提前把两个平台支持的算子列表拉出来做对比，标记出差异项。我们当时没做这一步，迁移时才发现某个自定义算子只在310上有优化实现，610上只能用通用实现，性能差了三倍。

技巧二：散热设计要按峰值功耗的1.3倍来留余量。很多团队按典型功耗设计散热，结果夏天高温或者长时间满载时就会降频。按峰值功耗的1.3倍设计，虽然成本高一点，但能保证全工况下的算力稳定性。

技巧三：双域控的启动顺序要错开。两个域控同时启动时，网络发现协议会产生广播风暴，导致启动时间变长甚至失败。让一个域控延迟5-10秒启动，可以避开这个问题。

技巧四：OTA升级前先做算力预算。每次OTA增加新功能前，用工具估算新增的算力需求，确保不会超出域控的算力余量。我们吃过亏，OTA后算力超了，只能紧急回滚。

7. 双域控方案的扩展方向与个人体会

双域控方案不是终点，它更像是一个过渡形态。从技术趋势看，未来可能会走向“中央计算+区域控制”的架构，把算力进一步集中，同时用区域控制器管理传感器和执行器。但在当前阶段，MDC 610/810双域控方案是一个务实的选择：它平衡了算力、成本、散热、功能安全等多个约束，能覆盖从L2+到L4的广泛场景。

我在实际项目中的体会是，双域控方案的成功与否，硬件选型只占三成，剩下七成靠软件集成和调优。算力分配、通信同步、散热管理、OTA策略，这些“软”的东西往往比“硬”的参数更能决定最终体验。如果你正在做类似的项目，我的建议是：尽早搭建原型系统，用真实数据跑通全链路，不要等到硬件定型了才开始调软件。

另外，华为的MDC工具链更新比较频繁，建议定期关注版本更新日志，新版本往往会优化算子性能或者增加新的调试功能。我们有一次升级工具链后，同一个模型的推理延迟直接降了15%，算是意外之喜。

最后分享一个小技巧：在双域控方案里，给两个域控各留一个“应急降级”模式。当810出现故障时，610可以接管部分核心功能（比如把AEB降级为简单的碰撞预警），保证车辆能安全靠边停车。这个降级逻辑要在设计阶段就规划好，不要等到出了问题再临时加。