大众的Telematics OCU3单元

5月份的时候，大众把 Golf 8 和斯柯达明锐等车型暂停交付，这款大众的畅销车配置了最新的 MIB3 和 OCU3（低配），而遭遇了 Telematic 传输数据的软件问题，按照大众的说法是 OCU3 控制单元中的软件可能无法可靠地传输数据。通过检索信息和材料，我们仔细来看这个 OCU3 不同变种的材料，事实上由于 EE 掌握这个部件，未来整车不同部门都需要这个部件可靠的运行把数据传回来，在紧急的功能下能够完成预警，比如配合新能源汽车热失控的 5 分钟预警，Telematics 需要肩负的责任更重。

01 Golf 上的 OCU3

OCU3 大众已经用了好几代，可追溯的是 OCU1 是在 2012 年左右开发的。这一代的 OCU 集成了 esim 卡，使用 Qualcomm MDM9240 调制解调器，支持的带宽包括 GSM 900/1800 、UMTS B1/B3/B8 、LTE FDD B1/B3/B7/B8/B20/B28A。OCU3 是数据传输中心，所有的 ECU 的数据都汇总到 OCU3 进行传输，分成两个配置，主要是 CAN 总线的差异。

图 1 OCU 3 低配的连接框图 

备注：大众有一篇介绍新能源汽车实时监控的文章，我们看一下改造的需求。实际上这个 OCU3 的软件，是大众自己主导开发的应用层 

图 2 大众在 MQB 平台上做的电动汽车的改造 

对于 LG 电子来说，整个板子就是帮忙做了硬件设计，其实拆开来看如下，由于有大量的通信要求，EMC 的要求是最苛刻的。 

图 3 OCU3 的 基本结构 

这是金属盖板下面的结构

图 4 OCU3 金属盖下的两块板 

这里有好几种可能性： 

1） 由于汽车运行的特殊性，数据传输模块的运行在各种条件下有可能出现没有上传的情况，这在车辆不同使用环境没办法避免 

2） 也就是如果主控芯片没有确认好是否传输完成，而且又遇上 Emergency 比如确实出来碰撞信号，这就使得 OCU3 的部分功能没办法实现 

3） 大众自己的软件在处理这些问题的时候，更加注重了功能实现，可能对于较为底层的东西没有做过多的深究 

图 5 OCU3 的主控芯片 按照 OCU3 

不同的版本要求，也就是说，大众之前对于这个 OCU3 更多的还是按照一个功能部件的开发角度来做的，大量的软件是集中在 MIB3 的主控单元上。上层定义的越多，整个软件也比较复杂，而涉及到底层数据传输的稳定性，又涉及到主控芯片需要做策略保证传输特性的，这个事情就可能比较复杂了。 

图 6 OCU 3 所支撑的功能（ID 系列的高配）

02 MEB 上的 OCU3

和 Golf 一样，MEB 上的 OCU3 也是一个更大和更多连接的连接终端，这么多软件连接，特别是 OTA 的要求，涉及到 OCU3 和 ICAS1 这个大型网关的连接。所以看来看去，在定义功能的特点上，大众是非常前瞻的规划了很多，但是这些软件全部分发出去，然后自己做，然后整个系统再测试。

图 7 MEB 上的 OCU3 连接要求 

如果这些软件是供应商做的，估计赔偿起来的价格是天文数字了，未来转型中也只有汽车企业担得起自己做软件的潜在责任，在底层错误导致的损失会非常大。

小结：目前大部分汽车企业对软件层面的信息交流非常少，我们其实也很难评估每个车企在这个方向转型的实际进度，只能说这条道路比实际想的要更坎坷一些