最近和几个做整车电子电气架构的朋友交流大家不约而同聊到一个话题岚图的中央集中式域控制器到底是怎么从前两年的架构图、Demo盒子一步步变成量产车上的真家伙的。中央集中式域控制器这个概念在行业里提了好多年PPT看过不少但真正把它从发布会概念落地到产线、跑通整车验证、再形成可复制的迭代路径的车企其实掰着手指头数得过来。岚图算是其中走得比较扎实的一家。它的天元SOA电子电气架构、OIB中央计算平台加VIU区域控制器这套量产方案不仅涉及硬件形态的变化更牵扯到软件架构、供应链体系、产线工艺甚至研发组织的重塑。这篇文章我不打算堆概念而是结合我这些年在车控、智能座舱、智驾项目里的实际经验把岚图这套中央集中式域控制器的量产逻辑和迭代路径拆开聊聊。无论你是在传统OEM做EE架构还是在Tier1做域控制器开发或者刚入行想搞清楚软件定义汽车到底怎么落地这篇都值得你花十分钟看完。1. 岚图为什么要押注中央集中式分布式架构的算力账与通信账先回到最根本的问题传统分布式架构到底哪里不行了逼得岚图这样的车企必须转向中央集中式1.1 分布式ECU时代绕不开的三座大山十年前一辆中高端车的电子电气架构是什么样全车少则三五十个、多则上百个ECU。每个ECU管一摊事儿比如车窗升降一个、雨刮一个、空调一个、网关一个、ESP一个、BMS一个。这些ECU通过CAN、LIN总线连在一起组成了整车的神经系统。这套架构在机械时代没问题但到了智能化时代三个问题开始压得研发团队喘不过气第一是软硬件深度绑定。每个ECU里的MCU微控制器都烧录了固定的固件功能逻辑和硬件死死绑在一起。想改个车窗防夹策略得先改软件再验证硬件然后更新产线刷写程序。如果是售后市场想优化功能对不起你得去4S店连诊断仪刷一整套固件升级周期漫长且风险高。第二是全车算力极度碎片化。每个ECU的MCU算力可能只有几十到几百DMIPS单个看都不起眼但合起来算力浪费严重——大量ECU在车辆行驶时只承担很小的活儿算力利用率极低。与此同时新的智能功能比如自动泊车、高阶辅助驾驶、多音区语音交互需要的是几十甚至上百TOPS级别的大算力分布式架构里找不到这样集中的算力池。第三是通信带宽的瓶颈。CAN总线的速率只有500kbps左右CAN-FD也就2Mbps到5Mbps。早期传个车窗状态、车速、故障码绰绰有余但现在整车动辄要传高清地图、传感器原始数据、多路视频流、OTA升级包这套老通信总线直接成为瓶颈。很多分布式架构的车上数据根本传不动。1.2 域集中式到中央集中式一次比一次彻底的收编大概从2018年前后行业开始转向域集中式架构把功能相近的ECU收拢到座舱域控、智驾域控、车身域控、动力底盘域控这几个大盒子里。每个域控制器集成对应的功率器件和MCU/SoC域内通过内部总线通信域间通过车载以太网连接。相比分布式这已经是一次巨大的简化。但岚图的方向更进一步它做的是中央集中式。简单说把原来多个域的大脑职能集中到一两个中央计算单元里车上的传感器、执行器则通过若干个区域控制器后来岚图命名为VIU就近接入。中央大脑负责算VIU负责跑腿。用个生活化的比喻分布式架构像是一个公司里每个部门都自己建了一套IT系统IT部门之间互不统属域集中式是几个大部门各自建了数据中心中央集中式则是全公司只保留一个核心数据中心各个办公室只设网络接口箱所有数据都汇聚到中央处理。1.3 中央集中式真正的杀手锏是SOA很多人以为中央集中式就是把几颗芯片放在一块主板上这是误解。芯片集成只是表象真正的杀手锏是软件层面实现了SOA面向服务的架构。在SOA架构下整车功能被拆成一个个独立的服务车窗服务、空调服务、座椅服务、能量管理服务、影音服务。服务之间通过标准接口通信上层应用可以灵活编排和调用这些服务。你可以把它理解成手机上的App——App可以独立开发、独立升级不用动手机系统底层。这就解决了分布式时代改功能必须动硬件的死结。一个新增的露营模式本质上是把空调、车窗、座椅、外放电这几个服务组合起来编排。这些服务在量产后依然可以通过OTA升级来增加App或服务组合硬件纹丝不动。岚图的天元架构就是奔着这个目标来的中央集成式硬件形态加上SOA软件架构两者缺一不可。只有中央集中式硬件提供足够的算力和统一的通信骨干SOA才有栖身之地只有SOA软件架构中央硬件投入才不会成为一笔一次性成本。2. 量产方案的核心拆解OIB中央大脑与VIU区域控制器怎么分工聊完了为什么就得看具体怎么落地。岚图在量产中采用的方案是典型的中央计算平台区域控制器架构这也是目前行业公认最有潜力走向中央计算终极形态的中期方案。2.1 OIB中央计算平台把座舱、智驾、整车控制合并在一处在岚图天元架构的量产描述里核心硬件是OIB中央计算平台和VIU区域控制器的组合。OIB承担了传统意义上座舱域控、智能驾驶域控、车身控制、中央网关等多重角色。这种融合带来的第一个好处是算力得到集约化利用。传统分布式架构里座舱芯片在跑娱乐功能智驾芯片在跑感知算法两者互不干涉但极少有机会互相借用算力。中央计算平台则允许系统按场景动态分配算力驻车时更多算力留给座舱影音和游戏行驶时算力重心向智驾感知倾斜。这种调度能力在传统的硬件烟囱式架构里根本实现不了。第二个好处是高速数据共享。在中央集中式架构里智能驾驶传感器摄像头、毫米波雷达、激光雷达采集的数据与座舱系统、车身控制、底盘控制位于同一个计算单元内部数据共享不再依赖外部以太网链路。比如行车记录仪功能可以直接复用智驾摄像头的数据流不需要再单独部署记录仪驾驶模式切换与悬架控制的联动也不再是网关转发几条CAN报文而是在统一计算环境内的服务调用延迟和可靠性都能做得更好。2.2 VIU区域控制器就近接入让线束瘦身OIB解决了算哪里的问题VIU解决的是怎么接得进来。传统整车线束是每一个ECU单独拉线到中央或者就近接网关线束总长往往达到23公里重量几十公斤。中央集中式架构下车辆被划分为前、中、后几个物理区域每个区域布置一个VIU该区域的传感器、执行器、灯具、开关都就近接到VIU上VIU再通过高速以太网上联到OIB。VIU并不是简单的接线盒它本身也包含MCU需要承担区域内的IO采集、信号预处理、局部执行逻辑和配电管理。例如车门区域VIU要管理车窗电机、后视镜折叠、儿童锁、氛围灯等多个负载同时还要做配电保护和故障诊断。岚图这套方案量产时最直观的成果就是全车线束的规模显著下降。线束少了整车重量就有下降装配工时减少故障节点也随之降低。这个成本收益其实比很多人想象的更直接——线束是整车利润率里看得见的项目。2.3 软件分层中间件、服务与App三层协同硬件确定了之后软件层面必须匹配。岚图基于SOA理念构建了一套从底层到应用的分层软件架构底层是操作系统和基础中间件。这里会采用车规级Linux、QNX或类AUTOSAR平台作为底座统一管理调度多个SoC和MCU的算力与通信。紧接着是一层服务中间件把底层硬件的能力封装成标准API让上层应用不关心具体硬件来自哪个供应商。中间层是车辆的原子服务和组合服务。车窗、空调、座椅这类是原子服务能完成单一功能露营模式、洗车模式、代客泊车这类属于组合服务上层编排多次原子服务来完成场景化功能。开发时可以像搭积木一样把服务拼起来。最上层则是用户交互层也就是座舱HMI、语音助手、手机App这些用户触达点。这一层天然适合快速迭代和手机生态的开发节奏对齐。这种分层的好处在于底层硬件变了上层服务接口不变甚至OIB从A芯片升级到B芯片中间层和上层应用都不需要重写。这就是软件定义汽车的底层逻辑——把硬件迭代与软件迭代解耦让车辆在生命周期内可以不断生长出新功能。3. 迭代路径从架构0到1再到1到N的三步走标题里我最想展开的是迭代路径这四个字。岚图这套中央集中式域控制器的迭代路径从行业视角看大致可以拆成三个阶段。这三个阶段不是简单的时间线而是一套逻辑递进。3.1 第一步架构0到1解决量产能不能过第一个阶段的目标很朴素把这个形态的架构装进车里通过所有法规测试和企业验证顺利从产线上开下来。岚图选择在旗舰MPV梦想家、轿车追光及后续车型上落地中央集中式架构。这一阶段最难的其实不是技术本身而是工程体系的配合。传统整车研发中座舱、智驾、车身、底盘各有一个团队和一套供应商但中央集中式架构要求这些部门共同对一台OIB负责。供应商也要从各交各的盒子转向合作供应一部分硬件、一部分服务。这个阶段岚图做了大量跨部门拉通工作这也是很多OEM做域控量产时卡壳最久的地方。从工程角度看0到1阶段必须解决的量产问题是硬件可靠性OIB集中了多块高算力芯片发热密度远高于传统ECU必须在结构设计阶段就解决散热路径。启动与休眠中央大脑需要管理整车的上下电流程代替传统的继电器和网关逻辑异常唤醒、低功耗休眠、防深睡漏电都要做全。产线刷写一致性一台车多个SoC的软件包同时刷写产线节拍压力很大要设计好刷写流程和防错机制。整车级功能安全当座舱芯片和车身控制移到同一个平台时安全完整性等级的分配、跨域通信的安全机制都要重新设计。3.2 第二步架构1到N解决一个平台能否撑起全产品线架构在旗舰车型上跑通之后下一个问题是如何复制到更多车型。车企不可能每款车重新开发一套域控。平台化的逻辑是同一套OIBVIU架构通过不同的软件配置和算法包适配MPV、SUV、轿车等不同车型。这就带来了一个很关键的设计要求——区域控制器的可裁剪性。SUV的车门线束和MPV的滑移门控制差异很大VIU的IO口数量和配电功率必然不同。架构规划上要预留可选的模块化设计某个区域的VIU可以高配版多带两路功率输出低配版少一路但核心通信协议和上联方式完全一致。这样供应商只需调整硬件小版本软件框架不用重写。软件层面的平台化更重要。同一套SOA服务模型要在不同车型间保持统一的接口定义空调服务、车窗服务、能量管理服务的接口标准一致上层App可以一次开发多车型复用。岚图后续车型快速承接天元架构能力靠的正是这层接口标准化。这一步还有一个隐性收益供应链议价能力提升。当多款车型共用一个中央计算平台时采购量级比单车型项目大得多芯片和内存模组的成本会被显著摊薄。越到后面这种平台架构的成本优势越明显。3.3 第三步能力升级解决算力与AI的需求如何快速上车第三阶段是面向未来两到三年的迭代当用户对座舱大模型、端到端智驾、V2X协同等功能的需求快速增长时中央集中式架构能否做到快速升级这是中央集中式相对域集中式的长周期优势。在域集中式架构中如果智驾域控算力不够你需要换一整个智驾盒子但中央集中式架构把座舱、智驾、网关统一到OIB平台后平台可以做代际升级——新一代OIB用更高的算力芯片替换旧平台因为软件接口已经标准化配套VIU和线束不需要大改整车上应用层的适配工作被压缩到很小。换句话说架构的迭代路径是一条从能造出来到能复用再到能升级的递进曲线。第一步验证技术可行性第二步验证商业规模性第三步验证长期生命力。岚图走这条路已经过了前两步第三步正在和行业同步演进。4. 量产实操中的硬骨头散热、网络安全与软件版本治理前面聊的是架构层面的宏观思路这一节我想把视角压低到工程师的日常。中央集中式域控制器真正到了量产阶段有几种问题是研发阶段不容易充分暴露的我挑三个最有代表性的展开。4.1 高算力集中带来的散热与结构挑战OIB把一个座舱芯片、一个智驾芯片、若干MCU和电源芯片放在同一个盒子里整板功耗轻松突破100W而传统ECU整板功耗可能也就几瓦到十几瓦。高功耗必然带来高发热如果散热设计不到位芯片降频、触发热保护都是小事严重了会影响整车可靠性。中央计算平台的散热路径需要做系统级设计PCB层要用更多铜箔来导热芯片上方加导热垫片连接到金属壳体壳体设计散热鳍片最终靠整车的风道或冷却液回路把热量带走。部分高算力平台甚至会引入液冷方案把OIB接入整车的冷却循环。这里有个工程上的两难OIB布置在哪个位置最优。放在手套箱后方维修方便但风道未必通畅放在中央通道散热路径好但占用乘员空间。岚图的做法是在平台架构早期就定义了OIB的布置区域并在整车造型冻结之前完成热仿真为散热风道预留足够空间。很多OEM在做这类项目时往往等到硬件热设计完了才想起回头找整车布置结果处处受限。4.2 网络安全从加个防火墙到开发流程内建中央集中式架构把全车的大脑集中到一起这意味着如果网络被攻破攻击面也空前集中。传统分布式ECU被攻破一个可能只是控制一个车窗中央计算平台被攻破攻击者理论上能影响整车几乎所有功能。因此网络安全在岚天元架构这类项目里不是配置项而是从需求阶段就进入开发流程的基础能力。量产方案里通常要覆盖这几层安全启动从BootROM开始逐级校验防止固件被篡改。安全通信车内的E2E端到端保护、SecOC安全车载通信机制防止报文被伪造或重放。车云链路远程控制、OTA升级包必须走双向认证的加密通道。证书管理整车每个安全域需要一套密钥和证书生命周期管理机制覆盖产线证书预置和售后证书更新。这一块日常开发中很容易被当成合规负担但我的经验是越早把网络安全渗透测试纳入开发迭代后期漏洞修补成本越低否则等法规强制要求来了一轮测试光整改时间就够项目喝一壶的。4.3 软件版本管理从少数几个ECU到几十个软件包的矩阵复杂度最后是软件版本治理这是中央集中式架构量产中看不见的战争。分布式ECU时代软件版本管理相对简单每辆车几十个ECU每个ECU一个固件版本版本矩阵虽然多但功能边界清晰。中央集中式架构下OIB内部可能同时运行着多个操作系统虚拟机和多个功能域软件包VIU里还有各自的固件加上服务层经常热更新整个整车的软件版本矩阵复杂度成指数级上升。量产过程中最怕出现的情况是整车下线时刷写的软件版本组合与测试验证过的组合不一致导致某个偶发问题只在特定版本组合下复现。排查这种问题往往要在上百个软件子版本号里逐层比对极其耗时。岚图的工程团队在软件版本管理上用的思路是软件包原子化整车版本快照把整车的所有可升级软件模块拆成一个个原子包每个包有独立的语义化版本号和依赖声明。整车出厂时打一个快照记录所有模块的精确版本组合作为售后问题回溯的基准。OTA升级时以快照配置管理为目标状态先校验依赖关系再执行刷写避免出现升级了A但没升级配套的B这种情况。这套体系还承担了一个很重要的量产职责产线刷写提速。中央集中式架构下全车软件包数量不少如果逐个子包依次刷产线节拍跟不上。实际的量产方案通常是并行刷写多个分区、利用高速车载以太网同时向多个控制器推送镜像配合缓冲区和断点续传机制把单车软件刷写时间压缩到产线可接受的范围。5. 从岚图的实践里我观察到的三件值得借鉴的事最后聊点我自己的观察。中央集中式域控制器并不是岚图独有的方向很多车企都在朝这个方向做但岚图的量产路径里有一些对其他团队有参考价值的东西。5.1 不要把域控做成又一个软件烟囱我做域控项目时见过一种很常见的做法硬件确实从分布式换成了域集中式但软件还是老一套——车身团队写C代码座舱团队写安卓App智驾团队跑自己的算法框架大家互不调用只是在物理上把几块板卡放进了一个盒子。这种伪集中式完全浪费了架构升级的意义。岚天元架构的做法更接近SOA的本意先定义服务再定义服务之间的标准接口最后才决定服务跑在哪颗芯片上。这个顺序很重要很多团队把顺序搞反了。先有服务抽象硬件才能被抽象成可替换的执行单元后续算力升级、芯片替换、车型复用时软件资产才能沉淀下来。5.2 量产验证要敢测坏天气和极端用户中央集中式域控制器带来的系统耦合度比分布式高得多一个问题往往会跨域传导。比如导航娱乐系统的一次异常唤醒可能导致整车静态电流异常。这类问题在实验室标准工况测试下很难暴露只有通过大量真实车辆、不同场景、不同气候条件的路测和公测才能碰得出来。量产实践给大家的建议是多做极端场景的故障注入测试拔掉某个域模块、断开某个网络骨干、软件回滚到旧版本再升到新版本、在弱网环境下反复OTA。这些测试看起来费时费力却是中央集中式架构量产避不开的功课。5.3 组织架构不随之改变E/E架构就是一张空壳这点最容易被低估。传统车企里座舱、智驾、车身、底盘分属不同部门汇报线不同、供应商体系不同甚至是互相竞争资源的关系。中央集中式域控制器要求这些团队坐到同一张桌子前共同对一台中央计算平台负责。岚图能快速落地这套架构一部分原因是它在研发组织上做了整合——把原先各域的软件团队、系统架构团队、测试团队拉通成跨域协同的作战单元。这也印证了一件事E/E架构升级的本质是研发生产关系的大调整技术只是显性的那一层。它对很多正在规划中央集中式架构的团队来说可能是最需要提前想清楚的问题。毕竟芯片和软件可以买架构可以抄但组织能力只能自己长。中央集中式域控制器的量产之路还远没到终点算力持续上探、AI能力下放、车路云协同逐步落地这些都会不断逼着这一代架构继续演进。但至少岚图已经用实际量产证明从分布式到中央集中式不是实验室里的空谈而是今天就能实现的事。这给整个行业带来的确定性比任何一份架构规划PPT都更有说服力。 岚图天元架构：中央集中式域控制器从架构到量产的迭代路径
最近和几个做整车电子电气架构的朋友交流大家不约而同聊到一个话题岚图的中央集中式域控制器到底是怎么从前两年的架构图、Demo盒子一步步变成量产车上的真家伙的。中央集中式域控制器这个概念在行业里提了好多年PPT看过不少但真正把它从发布会概念落地到产线、跑通整车验证、再形成可复制的迭代路径的车企其实掰着手指头数得过来。岚图算是其中走得比较扎实的一家。它的天元SOA电子电气架构、OIB中央计算平台加VIU区域控制器这套量产方案不仅涉及硬件形态的变化更牵扯到软件架构、供应链体系、产线工艺甚至研发组织的重塑。这篇文章我不打算堆概念而是结合我这些年在车控、智能座舱、智驾项目里的实际经验把岚图这套中央集中式域控制器的量产逻辑和迭代路径拆开聊聊。无论你是在传统OEM做EE架构还是在Tier1做域控制器开发或者刚入行想搞清楚软件定义汽车到底怎么落地这篇都值得你花十分钟看完。1. 岚图为什么要押注中央集中式分布式架构的算力账与通信账先回到最根本的问题传统分布式架构到底哪里不行了逼得岚图这样的车企必须转向中央集中式1.1 分布式ECU时代绕不开的三座大山十年前一辆中高端车的电子电气架构是什么样全车少则三五十个、多则上百个ECU。每个ECU管一摊事儿比如车窗升降一个、雨刮一个、空调一个、网关一个、ESP一个、BMS一个。这些ECU通过CAN、LIN总线连在一起组成了整车的神经系统。这套架构在机械时代没问题但到了智能化时代三个问题开始压得研发团队喘不过气第一是软硬件深度绑定。每个ECU里的MCU微控制器都烧录了固定的固件功能逻辑和硬件死死绑在一起。想改个车窗防夹策略得先改软件再验证硬件然后更新产线刷写程序。如果是售后市场想优化功能对不起你得去4S店连诊断仪刷一整套固件升级周期漫长且风险高。第二是全车算力极度碎片化。每个ECU的MCU算力可能只有几十到几百DMIPS单个看都不起眼但合起来算力浪费严重——大量ECU在车辆行驶时只承担很小的活儿算力利用率极低。与此同时新的智能功能比如自动泊车、高阶辅助驾驶、多音区语音交互需要的是几十甚至上百TOPS级别的大算力分布式架构里找不到这样集中的算力池。第三是通信带宽的瓶颈。CAN总线的速率只有500kbps左右CAN-FD也就2Mbps到5Mbps。早期传个车窗状态、车速、故障码绰绰有余但现在整车动辄要传高清地图、传感器原始数据、多路视频流、OTA升级包这套老通信总线直接成为瓶颈。很多分布式架构的车上数据根本传不动。1.2 域集中式到中央集中式一次比一次彻底的收编大概从2018年前后行业开始转向域集中式架构把功能相近的ECU收拢到座舱域控、智驾域控、车身域控、动力底盘域控这几个大盒子里。每个域控制器集成对应的功率器件和MCU/SoC域内通过内部总线通信域间通过车载以太网连接。相比分布式这已经是一次巨大的简化。但岚图的方向更进一步它做的是中央集中式。简单说把原来多个域的大脑职能集中到一两个中央计算单元里车上的传感器、执行器则通过若干个区域控制器后来岚图命名为VIU就近接入。中央大脑负责算VIU负责跑腿。用个生活化的比喻分布式架构像是一个公司里每个部门都自己建了一套IT系统IT部门之间互不统属域集中式是几个大部门各自建了数据中心中央集中式则是全公司只保留一个核心数据中心各个办公室只设网络接口箱所有数据都汇聚到中央处理。1.3 中央集中式真正的杀手锏是SOA很多人以为中央集中式就是把几颗芯片放在一块主板上这是误解。芯片集成只是表象真正的杀手锏是软件层面实现了SOA面向服务的架构。在SOA架构下整车功能被拆成一个个独立的服务车窗服务、空调服务、座椅服务、能量管理服务、影音服务。服务之间通过标准接口通信上层应用可以灵活编排和调用这些服务。你可以把它理解成手机上的App——App可以独立开发、独立升级不用动手机系统底层。这就解决了分布式时代改功能必须动硬件的死结。一个新增的露营模式本质上是把空调、车窗、座椅、外放电这几个服务组合起来编排。这些服务在量产后依然可以通过OTA升级来增加App或服务组合硬件纹丝不动。岚图的天元架构就是奔着这个目标来的中央集成式硬件形态加上SOA软件架构两者缺一不可。只有中央集中式硬件提供足够的算力和统一的通信骨干SOA才有栖身之地只有SOA软件架构中央硬件投入才不会成为一笔一次性成本。2. 量产方案的核心拆解OIB中央大脑与VIU区域控制器怎么分工聊完了为什么就得看具体怎么落地。岚图在量产中采用的方案是典型的中央计算平台区域控制器架构这也是目前行业公认最有潜力走向中央计算终极形态的中期方案。2.1 OIB中央计算平台把座舱、智驾、整车控制合并在一处在岚图天元架构的量产描述里核心硬件是OIB中央计算平台和VIU区域控制器的组合。OIB承担了传统意义上座舱域控、智能驾驶域控、车身控制、中央网关等多重角色。这种融合带来的第一个好处是算力得到集约化利用。传统分布式架构里座舱芯片在跑娱乐功能智驾芯片在跑感知算法两者互不干涉但极少有机会互相借用算力。中央计算平台则允许系统按场景动态分配算力驻车时更多算力留给座舱影音和游戏行驶时算力重心向智驾感知倾斜。这种调度能力在传统的硬件烟囱式架构里根本实现不了。第二个好处是高速数据共享。在中央集中式架构里智能驾驶传感器摄像头、毫米波雷达、激光雷达采集的数据与座舱系统、车身控制、底盘控制位于同一个计算单元内部数据共享不再依赖外部以太网链路。比如行车记录仪功能可以直接复用智驾摄像头的数据流不需要再单独部署记录仪驾驶模式切换与悬架控制的联动也不再是网关转发几条CAN报文而是在统一计算环境内的服务调用延迟和可靠性都能做得更好。2.2 VIU区域控制器就近接入让线束瘦身OIB解决了算哪里的问题VIU解决的是怎么接得进来。传统整车线束是每一个ECU单独拉线到中央或者就近接网关线束总长往往达到23公里重量几十公斤。中央集中式架构下车辆被划分为前、中、后几个物理区域每个区域布置一个VIU该区域的传感器、执行器、灯具、开关都就近接到VIU上VIU再通过高速以太网上联到OIB。VIU并不是简单的接线盒它本身也包含MCU需要承担区域内的IO采集、信号预处理、局部执行逻辑和配电管理。例如车门区域VIU要管理车窗电机、后视镜折叠、儿童锁、氛围灯等多个负载同时还要做配电保护和故障诊断。岚图这套方案量产时最直观的成果就是全车线束的规模显著下降。线束少了整车重量就有下降装配工时减少故障节点也随之降低。这个成本收益其实比很多人想象的更直接——线束是整车利润率里看得见的项目。2.3 软件分层中间件、服务与App三层协同硬件确定了之后软件层面必须匹配。岚图基于SOA理念构建了一套从底层到应用的分层软件架构底层是操作系统和基础中间件。这里会采用车规级Linux、QNX或类AUTOSAR平台作为底座统一管理调度多个SoC和MCU的算力与通信。紧接着是一层服务中间件把底层硬件的能力封装成标准API让上层应用不关心具体硬件来自哪个供应商。中间层是车辆的原子服务和组合服务。车窗、空调、座椅这类是原子服务能完成单一功能露营模式、洗车模式、代客泊车这类属于组合服务上层编排多次原子服务来完成场景化功能。开发时可以像搭积木一样把服务拼起来。最上层则是用户交互层也就是座舱HMI、语音助手、手机App这些用户触达点。这一层天然适合快速迭代和手机生态的开发节奏对齐。这种分层的好处在于底层硬件变了上层服务接口不变甚至OIB从A芯片升级到B芯片中间层和上层应用都不需要重写。这就是软件定义汽车的底层逻辑——把硬件迭代与软件迭代解耦让车辆在生命周期内可以不断生长出新功能。3. 迭代路径从架构0到1再到1到N的三步走标题里我最想展开的是迭代路径这四个字。岚图这套中央集中式域控制器的迭代路径从行业视角看大致可以拆成三个阶段。这三个阶段不是简单的时间线而是一套逻辑递进。3.1 第一步架构0到1解决量产能不能过第一个阶段的目标很朴素把这个形态的架构装进车里通过所有法规测试和企业验证顺利从产线上开下来。岚图选择在旗舰MPV梦想家、轿车追光及后续车型上落地中央集中式架构。这一阶段最难的其实不是技术本身而是工程体系的配合。传统整车研发中座舱、智驾、车身、底盘各有一个团队和一套供应商但中央集中式架构要求这些部门共同对一台OIB负责。供应商也要从各交各的盒子转向合作供应一部分硬件、一部分服务。这个阶段岚图做了大量跨部门拉通工作这也是很多OEM做域控量产时卡壳最久的地方。从工程角度看0到1阶段必须解决的量产问题是硬件可靠性OIB集中了多块高算力芯片发热密度远高于传统ECU必须在结构设计阶段就解决散热路径。启动与休眠中央大脑需要管理整车的上下电流程代替传统的继电器和网关逻辑异常唤醒、低功耗休眠、防深睡漏电都要做全。产线刷写一致性一台车多个SoC的软件包同时刷写产线节拍压力很大要设计好刷写流程和防错机制。整车级功能安全当座舱芯片和车身控制移到同一个平台时安全完整性等级的分配、跨域通信的安全机制都要重新设计。3.2 第二步架构1到N解决一个平台能否撑起全产品线架构在旗舰车型上跑通之后下一个问题是如何复制到更多车型。车企不可能每款车重新开发一套域控。平台化的逻辑是同一套OIBVIU架构通过不同的软件配置和算法包适配MPV、SUV、轿车等不同车型。这就带来了一个很关键的设计要求——区域控制器的可裁剪性。SUV的车门线束和MPV的滑移门控制差异很大VIU的IO口数量和配电功率必然不同。架构规划上要预留可选的模块化设计某个区域的VIU可以高配版多带两路功率输出低配版少一路但核心通信协议和上联方式完全一致。这样供应商只需调整硬件小版本软件框架不用重写。软件层面的平台化更重要。同一套SOA服务模型要在不同车型间保持统一的接口定义空调服务、车窗服务、能量管理服务的接口标准一致上层App可以一次开发多车型复用。岚图后续车型快速承接天元架构能力靠的正是这层接口标准化。这一步还有一个隐性收益供应链议价能力提升。当多款车型共用一个中央计算平台时采购量级比单车型项目大得多芯片和内存模组的成本会被显著摊薄。越到后面这种平台架构的成本优势越明显。3.3 第三步能力升级解决算力与AI的需求如何快速上车第三阶段是面向未来两到三年的迭代当用户对座舱大模型、端到端智驾、V2X协同等功能的需求快速增长时中央集中式架构能否做到快速升级这是中央集中式相对域集中式的长周期优势。在域集中式架构中如果智驾域控算力不够你需要换一整个智驾盒子但中央集中式架构把座舱、智驾、网关统一到OIB平台后平台可以做代际升级——新一代OIB用更高的算力芯片替换旧平台因为软件接口已经标准化配套VIU和线束不需要大改整车上应用层的适配工作被压缩到很小。换句话说架构的迭代路径是一条从能造出来到能复用再到能升级的递进曲线。第一步验证技术可行性第二步验证商业规模性第三步验证长期生命力。岚图走这条路已经过了前两步第三步正在和行业同步演进。4. 量产实操中的硬骨头散热、网络安全与软件版本治理前面聊的是架构层面的宏观思路这一节我想把视角压低到工程师的日常。中央集中式域控制器真正到了量产阶段有几种问题是研发阶段不容易充分暴露的我挑三个最有代表性的展开。4.1 高算力集中带来的散热与结构挑战OIB把一个座舱芯片、一个智驾芯片、若干MCU和电源芯片放在同一个盒子里整板功耗轻松突破100W而传统ECU整板功耗可能也就几瓦到十几瓦。高功耗必然带来高发热如果散热设计不到位芯片降频、触发热保护都是小事严重了会影响整车可靠性。中央计算平台的散热路径需要做系统级设计PCB层要用更多铜箔来导热芯片上方加导热垫片连接到金属壳体壳体设计散热鳍片最终靠整车的风道或冷却液回路把热量带走。部分高算力平台甚至会引入液冷方案把OIB接入整车的冷却循环。这里有个工程上的两难OIB布置在哪个位置最优。放在手套箱后方维修方便但风道未必通畅放在中央通道散热路径好但占用乘员空间。岚图的做法是在平台架构早期就定义了OIB的布置区域并在整车造型冻结之前完成热仿真为散热风道预留足够空间。很多OEM在做这类项目时往往等到硬件热设计完了才想起回头找整车布置结果处处受限。4.2 网络安全从加个防火墙到开发流程内建中央集中式架构把全车的大脑集中到一起这意味着如果网络被攻破攻击面也空前集中。传统分布式ECU被攻破一个可能只是控制一个车窗中央计算平台被攻破攻击者理论上能影响整车几乎所有功能。因此网络安全在岚天元架构这类项目里不是配置项而是从需求阶段就进入开发流程的基础能力。量产方案里通常要覆盖这几层安全启动从BootROM开始逐级校验防止固件被篡改。安全通信车内的E2E端到端保护、SecOC安全车载通信机制防止报文被伪造或重放。车云链路远程控制、OTA升级包必须走双向认证的加密通道。证书管理整车每个安全域需要一套密钥和证书生命周期管理机制覆盖产线证书预置和售后证书更新。这一块日常开发中很容易被当成合规负担但我的经验是越早把网络安全渗透测试纳入开发迭代后期漏洞修补成本越低否则等法规强制要求来了一轮测试光整改时间就够项目喝一壶的。4.3 软件版本管理从少数几个ECU到几十个软件包的矩阵复杂度最后是软件版本治理这是中央集中式架构量产中看不见的战争。分布式ECU时代软件版本管理相对简单每辆车几十个ECU每个ECU一个固件版本版本矩阵虽然多但功能边界清晰。中央集中式架构下OIB内部可能同时运行着多个操作系统虚拟机和多个功能域软件包VIU里还有各自的固件加上服务层经常热更新整个整车的软件版本矩阵复杂度成指数级上升。量产过程中最怕出现的情况是整车下线时刷写的软件版本组合与测试验证过的组合不一致导致某个偶发问题只在特定版本组合下复现。排查这种问题往往要在上百个软件子版本号里逐层比对极其耗时。岚图的工程团队在软件版本管理上用的思路是软件包原子化整车版本快照把整车的所有可升级软件模块拆成一个个原子包每个包有独立的语义化版本号和依赖声明。整车出厂时打一个快照记录所有模块的精确版本组合作为售后问题回溯的基准。OTA升级时以快照配置管理为目标状态先校验依赖关系再执行刷写避免出现升级了A但没升级配套的B这种情况。这套体系还承担了一个很重要的量产职责产线刷写提速。中央集中式架构下全车软件包数量不少如果逐个子包依次刷产线节拍跟不上。实际的量产方案通常是并行刷写多个分区、利用高速车载以太网同时向多个控制器推送镜像配合缓冲区和断点续传机制把单车软件刷写时间压缩到产线可接受的范围。5. 从岚图的实践里我观察到的三件值得借鉴的事最后聊点我自己的观察。中央集中式域控制器并不是岚图独有的方向很多车企都在朝这个方向做但岚图的量产路径里有一些对其他团队有参考价值的东西。5.1 不要把域控做成又一个软件烟囱我做域控项目时见过一种很常见的做法硬件确实从分布式换成了域集中式但软件还是老一套——车身团队写C代码座舱团队写安卓App智驾团队跑自己的算法框架大家互不调用只是在物理上把几块板卡放进了一个盒子。这种伪集中式完全浪费了架构升级的意义。岚天元架构的做法更接近SOA的本意先定义服务再定义服务之间的标准接口最后才决定服务跑在哪颗芯片上。这个顺序很重要很多团队把顺序搞反了。先有服务抽象硬件才能被抽象成可替换的执行单元后续算力升级、芯片替换、车型复用时软件资产才能沉淀下来。5.2 量产验证要敢测坏天气和极端用户中央集中式域控制器带来的系统耦合度比分布式高得多一个问题往往会跨域传导。比如导航娱乐系统的一次异常唤醒可能导致整车静态电流异常。这类问题在实验室标准工况测试下很难暴露只有通过大量真实车辆、不同场景、不同气候条件的路测和公测才能碰得出来。量产实践给大家的建议是多做极端场景的故障注入测试拔掉某个域模块、断开某个网络骨干、软件回滚到旧版本再升到新版本、在弱网环境下反复OTA。这些测试看起来费时费力却是中央集中式架构量产避不开的功课。5.3 组织架构不随之改变E/E架构就是一张空壳这点最容易被低估。传统车企里座舱、智驾、车身、底盘分属不同部门汇报线不同、供应商体系不同甚至是互相竞争资源的关系。中央集中式域控制器要求这些团队坐到同一张桌子前共同对一台中央计算平台负责。岚图能快速落地这套架构一部分原因是它在研发组织上做了整合——把原先各域的软件团队、系统架构团队、测试团队拉通成跨域协同的作战单元。这也印证了一件事E/E架构升级的本质是研发生产关系的大调整技术只是显性的那一层。它对很多正在规划中央集中式架构的团队来说可能是最需要提前想清楚的问题。毕竟芯片和软件可以买架构可以抄但组织能力只能自己长。中央集中式域控制器的量产之路还远没到终点算力持续上探、AI能力下放、车路云协同逐步落地这些都会不断逼着这一代架构继续演进。但至少岚图已经用实际量产证明从分布式到中央集中式不是实验室里的空谈而是今天就能实现的事。这给整个行业带来的确定性比任何一份架构规划PPT都更有说服力。