Telematics Control Unit（TCU）的系统化梳理

1、Telematics Control Unit (TCU)概述

TCU中文名为远程信息处理控制单元，很多场合都称为Telematics Box，又叫TBox，顾名思义，一般都为一个独立的盒子（如图2、图3所示），负责和云端的远程信息交互与控制。

TCU是车辆内置的电子设备，用于管理车辆与外部系统（例如云端或基础设施）之间的双向通信，从而实现远程信息处理服务。TCU 从各种车辆传感器收集数据，进行处理，并通过蜂窝网络、GPS 或WiFI/蓝牙网络以无线方式传输，用于紧急呼叫 (eCall)、车辆追踪、无线 (OTA) 更新和远程诊断等应用，从而增强连接性、安全性和运营效率。

TCU 的工作原理

数据收集：从车辆的车载系统和传感器收集数据，包括位置、速度和性能指标。

数据处理：需要处理和分析这些数据，以提取相关信息和洞察。

无线传输：处理后的数据随后通过蜂窝网络、GPS 和WiFi/蓝牙等技术以无线方式传输到外部服务器或云端平台。

外部通信：支持与外部网络通信，从而能够提供各种远程信息处理服务。

TCU的主要功能和应用

紧急服务 (eCall)：发生事故时自动将车辆状态和位置数据发送至紧急中心。

无线 (OTA) 更新：远程更新车辆系统的软件和信息。

车辆追踪：支持远程车辆追踪，有助于车队管理和被盗车辆追回。

远程诊断：支持车辆系统的远程监控和诊断，从而改善维护并提高效率。

导航和交通信息：为驾驶员提供导航辅助和实时交通信息。

车联网 (V2X) 通信：支持车辆与其他车辆、基础设施和行人之间的通信。

车队管理：为车队管理人员提供实时数据，以监控车辆性能、位置和驾驶员行为。

TCU 的优势

增强连接性：增强车辆与外部环境和服务的通信能力。

提升安全性：支持紧急呼叫和高级驾驶辅助系统 (ADAS) 等安全功能。

提升效率：通过远程诊断、维护更新和实时数据分析简化运营。

提升用户体验：提供实时路况、导航和互联信息娱乐等功能。

2、TCU系统方案

下图为TCU的示意图和爆炸图，但是下图没有备电电池部分，备电在后续章节中介绍。

下面罗列几种TCU的系统方案：

Ref：https://blog.csdn.net/qq_21994597/article/details/135116909

Ref：https://www.ti.com/solution/automotive-telematics-control-unit?variantid=20402&subsystemid=21698

3、TCU主要功能详解

下图为TCU的基本功能

四大主要功能

Ref：https://www.eet-china.com/mp/a325323.html

1、提供安全策略

安全启动，MCU支持Secure Boot，该模式启动后，MCU采用硬件算法确保启动后的ROM中所保存的程序是用户所期望的，其策略包括在做MCU升级包的时候，会生成Boot Key，升级时将其存放到HSM区域，MCU升级完成后设置Secure Boot模式生效，启动时计算的Boot Key与HSM中保存的Boot Key比对。
应用软件安全，应用安全目标是要保证TBox上的运行的服务或应用程序具备相应的保密性、完整性的防护措施，可以对抗逆向分析、反编译、篡改、非授权访问等各种针对应用的安全威胁，并确保应用产生、使用的数据得到安全的处理以及TBox的应用或服务与相关服务器之间通信的安全性，保证应用在提供服务时，以及应用在启动、升级、运行等各个模式下的安全性。
数据存储安全，数据安全目标是要保证TBox所采集、存储、处理、传输的数据的安全性，确保数据的机密性、完整性和可用性得到有效的防护，同时具有清除机制，保护数据生命周期各环节的安全性
通信安全，对内通信是指各个ECU之间的通信。其安全目标是根据应用场景在不同ECU通信和数据交换时，保证ECU不向电子电气系统发送伪造、重放等攻击方式的指令和数据，不非法占用内部总线资源，保证车内子系统和数据的保密性、完整性，以及在收到非法指令和数据时具有异常处理机制，保证ECU的功能正常
对外的话通信安全包括TBox与蜂窝网络的通信，与移动终端间的短距离通信（如：BT等），以及与其它车辆和路侧设施等的通信。对外通信安全的目标是根据应用场景在TBox与外部网络或设备建立通信连接时或在通信以及数据交换时，采取必要的认证、加密和完整性校验手段，对抗嗅探、中间人攻击、重放等多种针对通信的安全威胁，保证数据的保密性、完整性以及通信的质量

2、支持远程控制

远程控制车窗，用户通过手机APP远程控制车窗，TBox接收到远程控制车窗的命令后，如果整车总线处于休眠状态，则先唤醒整车网络，否则直接同时发送鉴权认证和控制车窗控制指令，并将执行结果以及失败原因反馈到TSP。在T-BOX 领域中，云端通常指由TSP （Telematics Service Provider）服务商提供的云平台。 TSP 服务商是专门为汽车和车载设备提供远程通信和数据服务的公司或组织。

远程控制门锁，用户通过手机APP远程控制车门锁，TBox接收到远程控制门锁的命令后，如果整车总线处于休眠状态，则先唤醒整车网络，否则直接同时发送鉴权认证和上锁/解锁控制指令，并将执行结果以及失败原因反馈到TSP。

除了车窗和门锁控制，还有其他类似的远程控制功能，比如远程充电控制、远程车门控制、远程寻车、远程空调控制、远程控制净化器、远程座椅加热控制等等。

3、远程车辆监控

车辆状态上报，当车辆被非法入侵BDCM发出非法入侵报警后，TBox采集车身状态信息和报警标志上传到TSP，TSP同步给APP报警信息，并通知车主。当车辆被异常移动，如碰撞、拖车、溜车等，触发TBox的G-sensor阈值，TBox将车身数据和报警标志上传给TSP，TSP将报警信息同步给APP并通知客户。

车辆信息周期上报，TBox采集车辆状态、位置等相关信息，周期性的上报到TSP。该功能在整车上高压正常，且T-box处于功能正常状态。

紧急求救功能eCall，eCall有两种发起的方式，一种是主动发起的方式，这种方式是由车上的人员主动触发车上的eCall按钮发起的；另外一种方式是被动发起。由于交通事故碰撞等原因导致车上的安全气囊弹出，TBox收到报文后，自动拨打eCall电话。车辆被碰撞之后或者手动按下SOS按键时，TBox采集车辆位置信息和车辆信息上传至TSP，而后自动拨打救援中心电话建立通话，并把通话过程显示在CID。

4、OTA

Tbox支持软件在线升级功能，负责自己和域内其它ETH节点的升级。在Tbox软件中会部署第三方提供的升级管理模块，负责升级包下载、备份、还原、升级状态管控、从节点升级包传输，同时还部署程序安装模块，负责Tbox自身固件和软件的刷写。 OTA升级方式主要有以下三种：

主动升级：由车主在HU大屏上点击设置，进入版本查询与升级，主动发起版本查询、下载、升级事宜，并且相应步骤都应给用户充分都提示和确认，多用于用户在取消推送升级后进行手动发起OTA升级。

推送升级：由OTA升级服务器后台推送版本升级，车主在HU大屏货手机APP上上点击确认，下载、升级由后台OTA升级程序自动完成，过程中给用户一次性授权提示和操作，多用于重大功能更新迭代，提高OTA升级覆盖率。

静默升级：主要用来强制性修复重大bug，上电满足版本查询和下载条件后Tbox就运行OTA功能，进行查询和下载，下载完成后等待升级条件满足，条件满足后进行强制性升级，升级时间段多选择在半夜12点后。

4、TCU的电源模式

TCU的电源模式非常重要，这里进行专门论述。

TBOX功能模块工作要求具有三种电源模式：

Ref：https://blog.csdn.net/yao_zhuang/article/details/131368494

1.Run Mode，全功能模式所有硬件模块正常工作，可进行CAN通讯、USB通讯、4G网络通讯、语音通话、蓝牙连接和以太网连接。 2.Suspend Mode，低功耗模式所有硬件模块正常供电，4G网络处于待机状态；唤醒源有：CAN通讯、USB通讯、4G网络通讯、语音呼入、短信接受、蓝牙连接、KL30断开、WAN主天线断开、IGN＝ON、SRS硬件碰撞信号。 3.Sleep Mode，睡眠模式网络以及其他功能模块全部关闭。4G模块断电，其他硬件模块保持供电，MCU处于待机状态；唤醒源有：CAN通讯、蓝牙连接、KL30断开、WAN主天线断开、IGN＝ON。

TCU中Telematics部分需要有专门的DC供电以及内部电池供电，到外部电源中断后，需要自动切换为备用电源供电。

另外GB/T 32960（《电动汽车远程服务与管理系统技术规范》），eCALL，DSSAD（自动驾驶数据记录系统）需要有电源冗余，备电功能。 Ref：https://news.eeworld.com.cn/qcdz/ic543139.html

另外TCU的静态电流需要在μA 级别：在TCU 的实际应用中，为实现汽车熄火后的远程控制或远程监控等功能，在待机模式下TCU的部分模块供电是不能关断的，以备随时唤醒；当汽车长时间例如7 天未点火时，为了减少对车载电池的损耗，TCU需从待机模式进入到深睡眠模式。图18 的电源架构对应的电路可实现上述功能并满足待机模式下mA 级别、深睡眠模式下μA 级别的静态电流要求，同时可满足车载电子产品测试标准的其他严格要求，例如电气性能、EMC、可靠性等。

备注：国标32960协议是新能源汽车的强制性法规，主要用于监控新能源汽车的车辆数据，车内数据通过32960规定的格式要求，上传到企业平台，再由企业平台转发到国家平台。 32960协议定义了车辆登入登出、实时信息上报、参数查询、参数设置、车载终端控制、终端校时、链接维持、数据补发功能。终端和平台采取TCP连接，32960协议在TCP的基础上，封装了数据格式，32960定义的实时数据、离线数据、心跳等数据，都封装成如下格式的报文，发送到平台。

5、基于MQTT的TCU心跳保活

这里直接给出结论：基于MQTT的TCU心跳保活，有效缩短了远程控车的消息时延，提升车主的使用感知，同时大大降低主机厂的运营成本。

MQTT：Message Queue Telemetry Transport，消息队列遥测传输

Ref：https://tttang.com/archive/1609/

MQTT是基于TCP/IP协议栈构建的异步通信消息协议，是一种轻量级的发布、订阅信息传输协议。可在不可靠的网络环境中进行扩展，适用于设备硬件存储空间或网络带宽有限的场景。使用MQTT协议，消息发送者与接收者不受时间和空间的限制。基于发布/订阅模式的物联网通信协议，简单易实现、支持 QoS、报文小等特点，专门为网络受限设备、低宽带以及高延迟和不可靠的网络而设计。由于以上轻量级的特点，是实现智能家居的首选传输协议。

Ref：https://www.modb.pro/db/334944 MQTT 协议在车联网中的应用

车辆数据主动上报：车载设备（T-box，车机等）作为车辆运行数据的收集者，基于固定频率将车内各类控制器、传感器等数据打包发送到平台端。此类数据一般可以按照上报数据的车型、车架号、业务数据类型等多个层级进行设计。
平台请求下发后车辆数据上报：当云平台需要获取车辆的最新状态及信息时，可以主动下发命令要求车辆上报数据。此类场景一般可以按照车架号、业务类型等层级进行主题设计。
平台指令下发：车辆远程控制是车联网业务中最常见、最典型的场景，各主机厂均在手机 App 中提供各种远控功能，例如远程启动、远程开车门、远程闪灯鸣笛等等。此类场景下，手机 App 发送控制命令至云平台，平台应用经过权限检查、安全检查等一系列操作后，通过 MQTT 将命令下发至车辆执行，车辆端执行成功后，异步通知平台执行结果。此类场景一般可以按照上行下行、车架号、业务类型、操作类型等多个层级进行主题设计。
车辆客户端请求后平台数据下发：在 SDV（软件定义汽车）的大背景下，车内很多配置是可以做到动态变化的，例如数据采集规则、安全访问规则，所以车辆在点火启动后，会主动请求平台最新的相关配置，若两侧配置不一致，平台侧会下发最新的配置信息至车辆，车辆侧实时生效。此类场景一般可以按照上行下行、车架号、业务类型等多个层级进行主题设计。

EMQX 作为全球领先的 MQTT 物联网消息中间件，基于分布式集群、大规模并发连接、快速低延时的消息路由等突出特性，能够有效处理车联网场景中高时效性业务需求，大幅度缩短端到端时延，为大规模车联网平台快速部署提供标准的 MQTT 服务。

关于MQTT，可以参考下面的系列文章：

https://www.modb.pro/db/249857
https://www.modb.pro/db/474666
https://www.modb.pro/db/381028
https://www.modb.pro/db/394624
https://www.modb.pro/db/408773
https://www.modb.pro/db/329699
https://www.modb.pro/db/337146
https://www.modb.pro/db/424012

基于MQTT的远控功能用户有控车需求时，操作手机APP，手机APP会把用户的控车请求发送到车厂的云平台，云平台收到后，将此请求下发到扯断TBox，TBox解析控制指令，发送控制报文到车内，并将控制结果反馈会用户，从而实现车门解闭锁、车窗升降、灯光控制、空调控制等功能。

基于MQTT的远程诊断功能传统车辆的诊断，用户基本上是通过仪表显示的故障图标来获知车辆当前是否有故障，如果故障图标点亮，用户需要将车辆开到4S店，由4S店的售后人员，拿着专业的诊断设备，获知更为详细的故障信息和解决方案，从而对车联郭进行维修。基于远程诊断功能，用户可以随时获知车辆当前的故障信息，随时知道自己车的状况，随时随地诊断车辆，基于大模型技术，甚至可以做预测性诊断的功能，在故障发生前，就进行预警，从而避免车辆运行时出现故障造成的伤亡事件。车联网心跳保活与远程唤醒除了在车辆行驶中进行相关数据传输上报，在车辆熄火状态下也可实现远程控车（远程启动、开启空调与开后备箱等）、OTA 升级等场景需求。为了给车主提供低时延、高成功率的使用体验，需要通过车联网平台与车机的心跳保活机制保持长连接状态，并在车辆熄火的情况下快速远程唤醒车机，实现远程控车。需要进行车联网平台的心跳保活和远程唤醒设计。构建大型车联网平台时，为了实现车机与平台的高效实时通信，通常采用长连接方式通信（如 MQTT、HTTP、私有化 TCP 长连接等），这里围绕 MQTT 协议长连接通信与远程车控唤醒场景进行详细介绍。 MQTT 本身也是采用 TCP 长连接的方式进行通信保活，TCP 长连接是指通过传输层三层握手建立的连接并长期保持，这样在应用层做消息传递请求的时候免去了 DNS 解析、连接建议等时间，大大加快了请求的速率，有利于消息的实时性。但同时我们需要端对端连接的维护和连接的保活。

MQTT 是标准的 RFC 协议，相比私有协议更加标准。同时 MQTT 协议面向物联网场景设计，具有如下功能优势：

完善的心跳机制
支持遗嘱消息
QoS 质量等级+离线消息
基于订阅发布的异步机制
低功耗，可以实现长连接低功耗保活和远程快速唤醒
采用 Topic 主题、支持安全扩展

使用 MQTT 协议建立车机与 TSP 等平台的长连接通信，可以有效解决对象唯一性与实时性等问题。其所具备的完善功能特性支持，适用于快速构建车联网业务，因此广泛应用于车联网 TSP 平台车控数据上报、远程控车、道路救援、高精地图、ADAS 和 C-V2X 等场景。

MQTT 协议设计了一套 Keep Alive 心跳机制：车机在与 Broker 建立连接的时候，我们可以传递一个 Keep Alive 参数，它的单位为秒。 MQTT 协议中约定：在 1.5 倍 Keep Alive 的时间间隔内，如果 Broker 没有收到来自车机端的任何数据包，那么 Broker 认为它和车机端之间的连接已经断开；同样地，如果车机端没有收到来自 Broker 的任何数据包，那么车机端认为它和 Broker 之间的连接已经断开。 MQTT 还有一对 PINGREQ/PINGRESP 数据包，当 Broker 和车机端之间没有任何数据包传输的时候，可以通过 PINGREQ/PINGRESP 来满足 Keep Alive 心跳通信和连接状态检测。

PINGREQ

PINGREQ 数据包没有可变头（Variable header）和消息体（Payload），当 Client（车机端）在一个 Keep Alive 时间间隔内没有向 Broker 发送任何数据包，比如 Publish 和 Subscribe 的时候，它应该向 Broker 发送 PINGREQ 数据包。

PINGRESP

PINGRESP 数据包没有可变头（Variable header）和消息体（Payload），当 Broker 收到来自 Client 的 PINGREQ 数据包，它应该回复 Client 一个 PINGRESP 数据包。对于 MQTT Keep Alive 机制，我们还需要注意以下几点：

如果在一个 Keep Alive 时间间隔内，车机端和 Broker 有过数据包传输，比如 Publish，车机端就没有必要再使用 PINGREQ 了，在网络资源比较紧张的情况下这点很重要；
Keep Alive 值是由 Client 指定的，不同的 Client 可以指定不同的值，我们可以根据车机硬件和业务特性使用不同的 Keep Alive 值；
Keep Alive 的最大值为 18 小时 12 分 15 秒（65535 秒），默认一般为 60s，我们可以根据车机的性能选择 10s、30s、60s 等值；
Keep Alive 如果设为 0，则代表不使用 Keep Alive 机制。

远程唤醒之前为了实现车辆离线状态下远程控车场景，平台通常采用短信或电话振铃的方式对车机端 T-Box 进行远程唤醒。这种传统方式存在以下弊端：

时延大且成功率不高：通过短信方式往往会有运营商短信延时，T-Box 唤醒后往往需要一定的时间启动，这个时候远程控车的消息有可能因为 T-box 未启动完成导致执行失败。
运营成本较高：假如业务场景 1sms/车/天，100 万车机的系统短信产生的费用成本将会很高。

所以现在主机厂大多结合越来越成熟的 T-Box 终端采用 4G/5G 网络通信（MQTT消息）唤醒方式，通过低功耗的保活消息实现车机长连接（有些主机厂部分车型还采用双连接）。当平台有车控消息下发时，车机端 T-Box 收到消息后迅速唤醒对应的 ECU 执行对应的车控指令，有效缩短了远程控车的消息时延，提升车主的使用感知，同时大大降低主机厂的运营成本。

6、自动紧急呼叫系统eCall

eCall 系统会在发生严重交通事故时自动联系紧急救援人员，将 GPS 坐标发送给当地紧急服务部门，并以无线方式发送安全气囊弹出和碰撞传感器信息。根据欧盟委员会的数据，eCall 将大幅缩短紧急服务响应时间，最高可达 50%；更快的响应时间将降低受伤程度并挽救生命。

汽车紧急救援呼叫系统（eCall）基本上由三个重要系统组成

车载电子系统（IVS，车载远程信息处理系统的组成部分）
电话通信网络（移动电话加固定网络）
紧急呼叫中心（公共安全应答点PSAP）

在GSM (2G)和UMTS (3G) 时代，eCall的主流解决方案是由美国高通公司提出的Circuit Switched eCall（In-band Modem）方案：

为了实现eCall功能，该方案不需要网络升级，而只需要在IVS终端新增通过In-Band Modem发送MSD以及接收PSAP发送的相关In-Band控制指令的功能。并保证车上安装有GPS卫星定位系统，IVS和车载相关传感器连接可以感知交通事故的发生并获得相关数据；而PSAP端则需新增加通过In-band Modem接收车辆发送的MSD和通过In-band Modem发送相关控制指令的功能。

随着4G LTE网络的广泛普及以及电路域网络技术的种种限制，CS eCall的局限性开始越发明显。由此，新的基于IMS（IP Multimedia System）紧急呼叫系统的NG-eCall（Next Generation eCall）解决方案开始逐步展露头脚

同CS eCall相比，NG-eCall利用IMS支持紧急呼叫业务的能力，可以大大缩短呼叫建立的时延，并且支持VoLTE语音和数据的并发，还可以在远程救援期间获取现场静态和动态的图像和音频信息。

Ref：https://www.ti.com/document-viewer/lit/html/SSZTBE4

Ref：https://zhuanlan.zhihu.com/p/429789884

Ref：https://scdn.rohde-schwarz.com/ur/pws/dl_downloads/dl_application/application_notes/gfm312/GFM312_1e_NG_eCall.pdf

全球认证

Ref：https://www.atic-zh.com/%E6%9C%BA%E5%8A%A8%E8%BD%A6%E7%B4%A7%E6%80%A5%E5%91%BC%E5%8F%AB%E7%B3%BB%E7%BB%9Fecall%E5%85%A8%E7%90%83%E8%AE%A4%E8%AF%81%E7%AE%80%E4%BB%8B/

7、嵌入式SIM卡（embedded-SIM）eSIM

eSIM 是 GSMA 制定的一项全球规范，支持对任何移动设备进行远程 SIM 配置。eSIM现在允许消费者在一台设备上同时存储多个运营商配置文件，并在它们之间远程切换，但一次只能使用一个。

Ref：https://www.gsma.com/solutions-and-impact/technologies/esim/wp-content/uploads/2018/12/esim-whitepaper.pdf

eSIM技术的核心价值，在于将通信能力从物理卡槽中解放出来。传统意义上的SIM卡，都是要插在手机上的，有一个物理接触的过程，而eSIM通过蚀刻技术将电路直接集成于芯片，嵌入到手机里面，体积仅为传统SIM卡的1/10，实现从“硬件”到“软件”的转变。

Tesla MCU主板上的通信模块背面有一个 eSIM 芯片。实际上，它只是一个普通 IC 封装中的普通 SIM 卡。

eSIM通过下载数字配置文件来激活和切换不同的电信运营商服务、号码和数据套餐。它提供了比实体SIM卡更大的灵活性和便利性，特别是在旅行时无需更换实体卡，并支持同时管理多个运营商配置文件，从而实现更流畅、更便捷的连接体验。

eSIM的工作原理

嵌入式芯片：eSIM是一种嵌入到设备主板上的微型芯片，而不是传统的需要插入卡槽的实体卡。
数字配置文件：运营商通过无线（OTA）方式将用户的身份信息和网络服务设置上传到设备的安全元件，形成一个数字配置文件。
轻松切换：用户通过扫描二维码或简单的设置流程，就可以下载和激活新的运营商配置文件，实现切换运营商或添加新的号码。

eSIM的优势

便利性：省去了实体卡的插拔过程，旅行时可以方便地在当地运营商处购买和激活当地的eSIM套餐。
灵活性：一台设备可以存储多个eSIM配置文件，方便切换使用不同的号码或运营商服务，例如工作和个人号码。
更高的安全性：无需取出实体SIM卡，降低了丢失或被盗的风险，而且信息是通过安全协议传输的。
节省空间：无需SIM卡卡槽，设备设计更灵活，也为其他组件预留了空间。

eSIM的应用

智能手机和移动设备：适用于新一代的智能手机、平板电脑和智能手表等设备。
物联网（IoT）：也广泛应用于物联网设备，如无人机、智能家居设备等，用于设备间的连接。

8、TCU的未来技术方向

TCU独立演进方向：

TCU+分离多天线；
TCU+组合天线模块；
TCU+内置天线，即TCU行业俗称的智能天线解决方案；

同时TCU的功能不断增多：4G/5G，GNSS，V2X，WiFi/BT，BLE，FM/DAB，UWB/BLE，TPMS等 TBox集成天线案例（智能天线）下图为2023沃尔沃的TCU集成天线解决方案，可以称之为TCU+内置天线的智能天线方案，虽然天线是鲨鱼鳍组合天线，没有完全内置，但是也是已经和TCU做成了一体化ECU。

Ref：https://www.eet-china.com/mp/a157210.html

下图为最新款Tesla中的TCU（集成了内置天线） Ref：https://olegkutkov.me/2025/05/12/custom-sim-card-in-tesla-model-3-2024-tesla-model-y-2025-and-cybertruck/ 随着新一代汽车（Model 3 Highland、Model Y Juniper 和 Cybertruck）的推出，特斯拉将蜂窝调制解调器从主计算机移到一个单独的单元——特斯拉远程信息处理控制单元 (TCU)。该模块集成了 LTE/5G 调制解调器、WiFi 和音频蓝牙。TCU 通过 1000Base -T1以太网连接到主计算机。

下图为东软TCU的技术形态方案：5G Box、智能天线、5G+V2X Box

智能天线：智能天线通过整合鲨鱼鳍天线和传统T-Box两大模块，实现对线束安装和管理成本的节省。2023年，智能天线的装配量超过五万。目前国内外多家供应商已经推出智能天线方案，包括东软集团、经纬恒润、联友科技、德赛西威、均联智行、大陆、博世等。如东软集团的智能天线采用all-in-one的设计理念，集成Tuner、GPS、Wi-Fi等软硬件，融合鲨鱼鳍和 T-BOX，对全车无线信号归集并数字化，可节省布线成本，并支持5G、V2X，目前该产品已应用于红旗H9、HQ9、E-HS9等车型。 TCU的独立天线组合模块：https://cn.vlg-solution.com/vehicle_antenna_cases/311.html

智能座舱域控和TCU组合演进方案

Two Box方案：智能座舱域控和TCU各自独立；
One Box方案：TCU作为模块集成进智能座舱域控；
One Chip方案：智能座舱域控SoC集成无线相关功能；

带通信模块的车机（这里是指One SoC方案）：部分主机厂将T-Box集成在其车机系统中。例如比亚迪DiLink 车机系统采用平台化设计，包括了中控屏和仪表屏，同时还配备了4G Modem和T-Box，以实现网络连接和车辆远程控制功能。核心部分采用LGA封装的高通SM6125核心模组，SM6125是一种SoM模组，类似常用的4G或5G通讯模组。

带通信模块的域控（这里是指One Box方案）：通信域控制器高度集成的设计和开发应用，可使主机厂在汽车智能网联零部件的成本投入直降1/3左右。目前，在主机厂中，主要有特斯拉、理想使用带通信模块的域控;在供应商中，高新兴物联车载通信域控制器已处于研发阶段，慧翰的车联网T-Box 正在向域控制器和中央处理器演进。理想采用的是One Box方案，如下图

Tesla在以往的产品中都采用了One Box方案。

Ref：https://olegkutkov.me/2021/06/10/tesla-model-3-us-lte-modem-replacement-and-some-reverse-engineering/ 调制解调器是安装在车载多媒体电脑 (MCU) 上的一块独立电路板。

目前，所有欧洲调制解调器都是 3.0 版本。然而，美版和欧版调制解调器之间有一个主要区别：美版调制解调器不使用 eCALL 连接器（欧洲紧急服务呼叫），而且实际上，美版 MCU 中也没有这个连接器的空间。

88EA1514 是88E1514 “Alaska” 以太网 PHY的汽车版本。该芯片用于与 MCU 进行数据（来自/到互联网）通信。有趣的是，它们并没有使用真正的以太网。所有模拟引脚均未连接。取而代之的是，该 IC 中有一个 SGMII 串行器/解串器 (SerDes)。SGMII 对用于与 MCU 板通信。电压调节器采用汽车级LM53625，配置为3.8伏输出。Telit模块需要这种不常见的电压值。