2026-11-09 19:06:41 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

宝马把软件集中到四个“超级大脑”之后

谈思实验室

2026年11月8日 17:42
上海

去阅读

点击上方蓝字谈思实验室

获取更多汽车网络安全资讯

一只小黑盒，走进新一代宝马

2023年慕尼黑车展，时任宝马集团董事长Oliver Zipse拿出一只小黑盒，向外界介绍后来被称为Heart of Joy的控制单元。它不是新的车机屏幕，而是宝马打算重新组织驾驶控制的一块核心硬件。到2025年2月，宝马把它装进高性能试验车BMW Vision Driving Experience，在美国斯帕坦堡的测试场验证动力与车辆动态控制。这辆试验车不量产，控制技术却要进入Neue Klasse新世代车型。

新一代BMW iX3官方行驶照片，英飞凌2026年合作公告配图，图片署名© BMW Group

这场转型有一条逐步落地的时间线。宝马在2025年9月发布首款Neue Klasse量产车型新iX3，同年在匈牙利德布勒森启用为它准备的新工厂。2026年8月，宝马的官方销售公告已经在讨论iX3上市供应增加对欧洲纯电业务的推动作用。因此，截至11月8日，Neue Klasse不能再仅仅被描述为一张面向未来的概念路线图。不过，不同市场的上市、配置和功能开放仍有差异，量产也不等于所有计划中的数字功能均已交付。

宝马为何要以一只控制盒来讲述新车？因为电动车上的驾驶感受，越来越依赖多个系统如何共同决策。驾驶者踩下踏板，车辆要同时判断电机扭矩、轮胎附着、能量回收与制动需求。如果这些任务由彼此独立的控制逻辑协调，信息交换与决策次序就会影响响应。宝马选择把一部分紧密相关的计算收拢，让软件更直接地塑造它想保留的品牌特征。

这也改变了安全工作的重心。过去，可以围绕一个个部件划定开发与验收范围；当计算与软件服务被更多功能共用，车企还需要证明部件之间的边界可靠、共用平台的变化不会破坏其他功能。宝马没有在这次转型中宣布放弃供应商，而是在自研驾驶控制、外部基础软件与半导体伙伴之间，重新划分技术主导权。判断它走到了哪里，要看实际架构和研发分工。

四个大脑，背后仍有一张分工网络

宝马2025年3月公布的方案，把主要计算集中到四台高性能计算机，分别服务于驾驶动态、驾驶辅助、信息娱乐，以及车身与舒适等基础功能。Heart of Joy负责其中的驾驶动态；Panoramic iDrive的计算平台承载显示、交互与信息娱乐；其余平台各自处理驾驶辅助和车辆基础状态。四个“超级大脑”是功能分工的表达，不能理解为整车只剩四个控制器，更不能把驾驶辅助平台的名称当作车辆已经具备无人驾驶能力的证明。

新架构同时改变了布线方式。以往按功能分别铺设的长距离连接，更多经由就近的区域控制器汇集，再连接中央计算。英飞凌2026年2月披露的供货资料称，四台中央计算机由三台区域控制单元支持，而牵引逆变器、电池管理和车载充电等任务仍有末端控制器。这解释了集中计算与区域架构为何可以同时存在：前者决定重要任务在哪里计算，后者优化信号与供电怎样到达各个部件。

区域化的价值并不只在于线束减重。车辆处于行驶、充电、停放或升级时，需要工作的部件不同。英飞凌的说明还介绍，智能电子保险丝能够支持软件控制的电源管理，按车辆状态关闭不需要的用电设备。于是，电源状态也进入软件定义范围。对安全设计而言，重启哪个区域、故障后保持哪些部件供电，都必须和功能依赖一起验证；不能只测试正常行驶时的数据畅通。

宝马官方简化示意图：Neue Klasse的区域架构

中央计算提高了跨功能协调能力，却没有消除隔离需求。导航需要读取位置，不应因此获得修改动力控制参数的权限；娱乐应用能够联网，也不代表它可以任意向驾驶控制发送指令。这些是集中架构普遍需要满足的边界，而不是已经发现的宝马漏洞。评估此类平台，应检查通信接口、进程权限与故障传播路径，不能仅凭处理器数量或算力倍数判断安全程度。

驾驶控制的自研，必须接上整车验证

Heart of Joy体现了宝马希望自己掌握的那部分技术。官方技术介绍称，它把动力、制动、充电、能量回收以及部分转向相关控制放进同一控制单元，并与自研BMW Dynamic Performance Control软件配合。它的目标不是让车内所有功能都在一块芯片上运行，而是减少驾驶动态控制过程中原本分散逻辑之间的协调延迟，让减速、扭矩分配与车辆稳定性更自然地衔接。

在2025年的介绍中，时任研发负责人Frank Weber把这种整合与宝马长期追求的驾驶体验联系起来。试验车轮圈还能用不同颜色展示加速、回收与摩擦制动，帮助观察者理解系统怎样工作。这里的重点不在表演本身：当减速更多由电机回收完成，控制系统就必须在回收能力变化时与摩擦制动平顺交接，不能让驾驶者为软件分工承担额外操作负担。

真正困难的场景，往往发生在最不适合展示的边界。低温、电池接近满电或路面附着变化，都可能改变能量回收的可用程度；传感器异常或通信中断，则要求系统保留可预测的退化行为。以上是针对这类架构的工程分析，不能据此断言宝马存在相关缺陷。测试需要把软件状态、车辆状态与物理条件组合起来，而不是只记录一圈赛道跑得多快。

这也是从概念验证走向量产必须跨过的距离。高性能试验车可以帮助工程师扩大测试边界，却无法代替量产硬件、不同配置与真实用户使用环境的完整验证。宝马2025年年报把iX3的发布、工厂启用和后续产品扩展作为同一条转型线索；从软件角度看，工厂开始装车之后，版本配置、出厂标定与售后维护也就成为产品的一部分。车辆交付标志着验证场景扩大，维护责任随之开始。

自研之外，软件工厂和伙伴怎样接起来

在四台计算机之上，宝马又安排了连接不同平台的共享服务层。2026年投资者资料把网络安全、OTA、人工智能平台和数据管理列为这层软件提供的共用能力。其意义在于，应用不必每次重新实现一套基础服务；同一项修复也有机会惠及更多功能与车型。但共享层一旦修改，受影响范围就需要按依赖关系追踪，不能仍以单一应用作为全部验收边界。

负责电子与软件业务的Christoph Grote在2025年强调软件连续性：软件持续演进，而非每代汽车重新开始。宝马同时介绍了名为CodeCraft的云端开发工具链，支撑全球团队构建软件。这样的变化把汽车开发从单次项目，推向维护多个版本分支的长期工作。持续复用可以减少重复劳动，却也要求旧车型的计算资源、接口兼容性和服务年限始终有人管理。

基础软件仍依赖专业伙伴。QNX在2026年1月公告中称，其实时操作系统与虚拟化技术将支持Neue Klasse的安全关键系统，涉及确定性的实时行为、域隔离和故障情况下的运行能力。宝马软件平台负责人Chris Salzmann也在该公告中说明了可信伙伴的重要性。这是供应商及合作方的技术说明，并不构成所有车型、所有工作负载均已通过独立安全审计的结论。

对整车厂而言，自研与采购并不是责任的分界线。一个基础组件的漏洞，由供应商修补后，仍需要确认哪些车型使用该版本、补丁是否改变实时性能、是否需要联动升级其他组件。车企必须能从在售车辆追溯到组件、配置与维护责任人。若只有一份交车时的静态清单，后续更新又没有同步记录，软件规模越大，定位受影响车辆反而越困难。

宝马官方软件栈简图：四计算平台之上有各自的软件平台，共享服务层连接OTA、网络安全与数据管理等能力。

因此，平台复用带来的效率，应与变更影响分析一起衡量。更新一个地图界面，通常不需要重新验证全部车辆动态；改变共享通信、身份认证或底层调度，则可能触及多个域。合理的研发流程要能区分这些影响，并为高风险变化留下审查与验证证据。这里提出的是编辑分析，而非声称宝马已经公开了全部内部流程，也不把供应商声明当作零风险承诺。

从开发团队的角度看，这还涉及工作成果怎样交接。功能工程师要交付需求与异常行为，平台团队要交付稳定接口与资源边界，供应商要交付可维护的组件和缺陷信息，整车团队则要确认组合后的行为。任何一方的单独合格，都不能自动替代整车结论。宝马希望软件跨代延续，实际上也就需要把这些知识跨代保存，避免人员或组织变化之后，只剩二进制文件而找不到设计依据。

2026年的数据选择，把责任推到云端

软件平台开始持续演进，真实道路数据的价值也随之提高。宝马面向德国及逐步扩展的欧洲经济区客户车队视频数据隐私公告写明，自2026年4月起，部分车辆可在用户事先明确同意、特定事件触发时采集外部视频与传感器数据。它不是所有车辆的连续视频上传。公告进一步说明，自9月起逐步调整流程：在法律允许范围内，未打码视频先进入后端隔离环境Blackbox自动处理，确有必要供开发人员人工访问之前，再遮蔽人脸与车牌。

宝马给出的理由，是希望机器学习保留行人视线、头部运动等信息，避免提前遮蔽影响训练；公告同时列出加密、角色权限和技术隔离等措施，并称高通只能访问已打码的数据。这些内容是企业公开说明，尚不能代替独立验证，也不应被改写成宝马已经发生视频泄露。它真正展现的是一项具体取舍：更完整的数据可能改善研发，但更强的后端保护必须同时跟上。

这一取舍值得放进软件转型故事，而不能只留在隐私条款里。把打码时点从车端移到后端，意味着风险控制更加依赖云环境：哪些系统能够接触原始材料、自动任务如何取得凭据、人工例外访问怎样审批，都变得关键。保护对象也不只有购买车辆并同意采集的用户，还包括被镜头偶然记录的其他道路参与者。数据可用性提高之后，责任范围可能随之扩大。

宝马的数据生态说明允许客户在车辆隐私菜单、My BMW应用及ConnectedDrive网站调整相关分享设置。对平台运营而言，界面上的选择必须真正传递到采集端和后端任务，撤回同意后也要处理后续采集与历史记录的不同状态。仅在界面展示一个开关，不足以证明整条链路遵守了选择；需要能检查策略生效、访问记录与留存结果。这是对数据治理可验证性的要求，而不是对宝马开关失效的指控。

一代车的交付，变成多年软件服务

持续演进已经出现在用户可感知的功能里。宝马2026年9月30日的秋季更新公告介绍，Operating System X车型将从10月起获得整合导航、车辆周围环境与辅助驾驶信息的三维视图；Drive Challenge与My BMW应用的连接则预计年底提供。两者的时间表不同，不能因为同在一份公告里，就认为全部功能已经同步到所有车辆。软件转型要求车企把承诺拆成可核实的车型、市场、版本和开放时间。

从工程角度看，驾驶者看到的只是一项新功能，后台却可能涉及地图服务、账户、车辆状态以及车内显示。车企需要限定每个服务得到的数据范围，也需要在服务中断时让核心驾驶任务保持清晰。娱乐和个性化可以持续扩展，控制权与数据访问权却不能随着功能数量一起无边界增长。集中平台若能提供一致的权限与审计机制，就有机会减少各应用重复实现时的遗漏。

更长的生命周期还意味着退出机制同样重要。车辆转手、用户更换账户、部件替换和云服务结束，都需要正确解除身份与车辆的关联；维护团队也需要知道某项依赖何时停止获得补丁。跨代软件连续性是一项有价值的产品方向，但兑现它，不能只保证新功能可以往旧车上推，还要保证旧硬件能够持续获得适合自己的安全维护。

产品说明也应随着软件同步变化。车主需要知道当前装了什么版本、哪些能力依赖网络或订阅、哪些升级需要车辆停放，以及出现问题后由谁处理。若一项服务改变数据采集方式，信息更新就应进入用户能够看见的沟通渠道，而不能只改变后台流程。技术平台越统一，向用户提供一致解释的条件越好；是否利用这一条件，最终仍取决于产品与运营团队的选择。

从小黑盒到iX3，宝马已经把驾驶体验、电子架构和软件开发放进同一场产品变革。四个“超级大脑”提供的是重新组织能力的基础，而不是安全工作的终点。接下来的考验，是让供应商修复能够准确进入车辆，让用户的数据选择能够落到系统，并让多年后的车主仍能得到可解释、可维护的产品。软件越接近汽车的核心，整车厂就越需要对这些连接持续负责。

end