车联网域——T-Box

10.1 Tbox 是什么？✓

T-Box 是车载网络连接的终端，一般具有如下功能：

系统架构与硬件形态

• 别名：OCU（Online Connectivity Unit，在线连接单元）、TCU（Telematics Control Unit，远程信息处理单元）。
• 整车连接：T-BOX → Gateway（网关）→ BCM / ADAS / PDC / IVI 等。
• 硬件形态：
• 独立式：硬件上将云端数据与车端数据隔离，有利于信息安全；
• 非独立式：
• 鲨鱼鳍 + T-BOX（智能天线）：归集整车无线信号，节约布线成本。厂商：大陆（奔驰、沃尔沃 XC90）、东软（红旗 E-HS9、H9、HQ9）；

• 网关 + T-BOX（智能网关）：提高数据处理效率。品牌：上汽大通、红岩、跃进、蔚来；

• 多模块融合：特斯拉 Model S Plaid 座舱域控（娱乐+网关+T-BOX）、深蓝 SL03 整车域控（VCU+网关+T-BOX+电子换挡器）、比亚迪 DiLink 智能网联系统（中控屏+仪表屏+T-BOX），云端数据与车端数据做了隔离。

互联通信方式

台架/实车功能模块（思维导图）

• 主数据录入：VIN 码（车架号）、IMEI 码、ICCID 码、MAC 地址、MSISDN 码；绑车、解绑、蓝牙钥匙；车型、功能。
• 配置激活：密钥交换（与 TSP 建立握手）、绑车（APP 版本、型号、系统）、激活（车机激活、点火激活）、钥匙学习（与 BCM 建立握手）。
• 车控功能：蓝牙钥匙车控（解锁、上锁、后备箱、寻车）、远程车控（解锁、上锁、后备箱、寻车）、发动机点火、自动泊车、发动机相关（启动、空调、座椅加热、空气净化）、车窗、天窗、闪灯、鸣笛。
• 网络测试：路测、救援电话。
• FOTA：分包、全量包、预约、强制。
• 台架 / 实车：网络、定位、车辆状态、车控、FOTA 升级。

10.2 Tbox 的状态✓

主要分为三种状态：监听模式（浅睡眠）、睡眠模式（深度休眠）、运行模式（全速工作）。

2.1 监听模式（Listen Mode）——"浅睡眠，时刻待命"

• 状态描述：车辆熄火后的主要待机状态，T-BOX 未完全睡着，4G/LTE 模块依然连网（类似手机锁屏但连着 WiFi）。
• 功耗标准：< 3mA @12.5V（低功耗，但比深度睡眠高）。
• 核心能力：能接收手机 App 下发的指令（通过 UDP 数据包）、能接收短信（SMS）、能被蓝牙唤醒（手机靠近车辆）。
• 唤醒/触发条件：
• 定时唤醒（TBOX_Power_Timer_1）：到设定时间点醒来汇报数据；
• 外部指令：收到短信、UDP 数据、蓝牙信号；
• 网络异常：掉网时必须醒来进行重连。
• 跳转运行模式条件（任一）：①TBOX_Power_Timer_1 超时；②蓝牙模块唤醒；③DiagCAN 或 HybridCAN 被网络唤醒（HybridCAN 预留，暂不实施）；④收到 UDP 数据报文；⑤SMS 报文；⑥LTE 移动通讯模块检测到掉网。

2.2 睡眠模式（Sleep Mode）——"深度休眠，省电优先"

• 状态描述：为防止电瓶亏电设计的"冬眠"状态。
• 功耗标准：< 250μA（0.25mA）@12.5V，比监听模式省电 10 倍以上。
• 硬件状态：4G 模块关闭（彻底断网，无法接收远程指令）；MCU 掉电（主处理器停止工作）；仅保留 RTC（实时时钟，用于定时叫醒）和蓝牙/Gsensor（用于被钥匙或震动唤醒）。
• 进入条件：车辆长时间无操作；电瓶电压低（见下文逻辑）；网络极差（见下文逻辑）。

2.3 运行模式（Running Mode）——"全速工作"

• 状态描述：车辆行驶中或刚启动时的全功能状态，所有模块（GPS、4G、MCU 等）全开。
• 功耗标准：< 300mA @12.5V（高功耗）。
• 主要任务：实时上传车辆数据、处理复杂的远程控制、进行 OTA 升级等。
• 进入逻辑：通常由车辆点火（ACC ON）、收到远程指令、或从 Listen/Sleep 模式被唤醒后进入。

2.4 智能切换逻辑（决策大脑）

A. 电压保护逻辑（保护电瓶）

车辆熄火（SysPwrMd=OFF）后，TBOX 监测电瓶电压（KL30）：

1. 严重亏电（<9V）：满足切换到 Listen 的条件则勉强进入 Listen（可能尝试汇报一次低电压报警）；满足切换到 Sleep 的条件则直接强制进入 Sleep，不再响应远程指令。
2. 电压偏低（9V ≤ KL30 < 11V）：直接进入 Sleep 模式。电压不足以支撑长时间 4G 通信，强行工作会导致车辆无法启动。

B. 网络异常处理逻辑（防止"累死"）

信号极差区域（如地下室）不断尝试连接基站非常耗电，因此设定"断网保护机制"：

1. 掉网重连：Listen 模式下发现掉网，TBOX 唤醒进入 Running 模式尝试重连；
2. 失败惩罚：重连失败直接去 Sleep；频率限制——30 分钟内重试 6 次未连上，或车辆熄火后累计重试 30 次失败，判定此处无信号，强制进入 Sleep 模式，停止无效尝试。

暗电流要求：≤1mA。

2.5 电源模式状态转换

• Listen → Running：收到 TSP UDP 报文 / 收到 TSP SMS 报文 / CAN 网络被唤醒（Diag CAN、Hybrid CAN 等）/ TBOX_Power_Timer_1 超时 / 蓝牙模块唤醒 / LTE 移动通讯模块检测到掉网。
• Running → Listen：没有 TSP UDP 报文发送（含超时机制等待发送报文）、连续 2 分钟未成功收到 TSP UDP 报文、CAN 网络休眠、CALL 业务结束（如 CallBack 使能，含 CallBack 结束）、TBOX_Power_Timer_1 未超时、COMPLETED_INITIAL_KEY_EXCHANGE = Completed、LTE 模块无任务、VBUS = 0（USB）、蓝牙断开、SysOpnMd = 0x2 | 0x4。
• Running → Sleep：CAN 网络被唤醒（Diag CAN、Hybrid CAN 等）且无 TSP UDP 报文发送、TBOX 网络休眠、TBOX_Power_Timer_1 超时、连续 2 分钟未成功收到 TSP UDP 报文、CALL 业务结束、LTE 模块无任务、VBUS = 0、蓝牙断开、COMPLETED_INITIAL_KEY_EXCHANGE = Completed、SysOpnMd = 0x2 | 0x4。
• 注：APP_MODE 定义见章节 3.1.3；VBUS 判断见章节 3.4.3；Hybrid CAN 预留暂不实施；CALL 业务包含 bCALL、eCALL；整车工作模式 SysOpnMd 定义见章节 3.1.4。

10.3 Tbox 功能✓

通讯链路：手机 APP → 云端服务器 → 车载 T-BOX → 整车网络唤醒 → 域控制器 → 执行器 → 状态逆向回传。

功能分类总览

手机 APP 远程功能：车门控制、车辆启动、充电管理、空调控制、车况查询/诊断、车辆定位/寻车、车主服务（查找充电桩、加油站、停车场等）、预约保养/维修。

3.1 远程车辆控制

远程控制主要由三部分组成：手机客户端（Android/iOS）、TSP 云端、Tbox 车端。

• 手机客户端链路：手机网络传输到 TSP 云端 → TSP 云端下发命令到车机 TBOX 端 → TBOX 通过 GW 中央网关传送到车辆各个 ECU → 功能实现后原路返回到手机客户端。

3.2 车辆状态的查询

• 1. 车辆查找：测试查找成功、重复查找。
• 2. 行程查看：查看历史行程、查看多条记录、生成行程报告。
• 3. 车辆状态：机油寿命、燃油数量、公里数、四轮胎压。

3.3 车辆控制

车门状态、后备箱状态、车窗、天窗、大灯、车门锁定、闪灯鸣笛。

测试方式

• 主要分为：手机端专门测试人员、车端测试人员、服务器端测试人员。
• 手机端和服务器端测试，测试方法和原理与软件测试一模一样；车端测试是单独的。
• 车端远程开/闭车锁：蓝牙已连接状态下执行解锁、闭锁、开窗、升窗、寻车、开后备箱等（详见原图 APP 界面）。

电源档位

• 燃油车：
• LOCK/OFF：全车断电，小电瓶（12V 电瓶）待机，防盗系统工作；
• ACC：部分通电，可听歌、看视频、收音机；
• ON：全车通电；
• START：发动机点火启动。
• 新能源车：
• 什么时候是低压：靠近解锁或任何方式解锁时，唤醒信号通过网关转发至整车控制器（VCU）并将其唤醒；此时部分控制模块和低压电路通电（如中控、仪表显示），动力系统（驱动电机、高压电池主接触器）不通电，整车由低压蓄电池供电。
• 什么时候上高压：踩下刹车踏板 + 按下启动按钮（或车辆设定的其他启动方式）→ 车辆自检确认系统正常 → 接通高压继电器 → 高压电池与驱动系统连通，进入高压工作状态。
• 新能源车有两个电源：小电源（测试时很多车在后备箱）；高压互锁开关（前机盖下面，测试车很多有插口）。

远程启动和非远程启动的区别

• 远程启动：
• 无需人到车内。通过遥控钥匙（短距离，智能钥匙/蓝牙钥匙一般 3~5 米）或手机 App（依托网络 4G/5G，不限距离）发送信号触发启动；
• 原理：钥匙/App 发出指令 → 车辆接收并验证（密钥）→ 启动发动机/电机（燃油车启动发动机，新能源车多为启动空调、动力系统预激活）；
• 例：手机 App 点"远程启动"，通过 TBOX 及云端（TSP）传送到 BCM 车身域，实现提前预热，下楼直接开车。
• 非远程启动（手动启动）：
• 传统油车：驾驶员进入车内，物理钥匙拧动（传统车型）或一键启动按钮（无钥匙进入车型）手动触发；
• 原理：钥匙解锁车辆 → 人进入车内操作启动按键/拧钥匙（密钥）→ 启动发动机/电机；
• 新能源车：蓝牙钥匙（3~5 米）靠近自动解锁、NFC 卡片刷门解锁、硬控按键解锁（5 米）手动按钥匙。
• 场景举例：人在上海、车在北京，停车挡住别的车需挪车 → 远程启动 → 远程解锁 → 人进入倒车 → 操作完毕远程熄火、远程闭锁。
• 优先级：非远程启动（钥匙启动）说明人就在车旁、有人参与，人优先级最高，此时不可进行远程操作。

内部流程（远程解锁/闭锁一般步骤）

1. Tbox 收到 TSP 云端服务器车门开锁请求（手机车企绑定后 APP 发送）；
2. Tbox 执行请求，在整车网络中发送对应的 CAN 或 LIN 信号（主要即车门解锁相关请求）；
3. 测试过程中通过 CAN 工具发送 BCM_RmoteLock 信号（0x1 表示打开，0x0 表示关闭），对应 ECU 执行；
4. 再发送 BCM_RmoteLockFeedback 信号查看对应值，实现车门解锁；
5. 拿到反馈结果返回给 TSP 云端，TSP 云端再返回给用户。

BCM_RmoteLockFeedback 反馈值定义：0x0=NoFeedback；0x1=成功；0x2=车门未关；0x3=行李箱未关；0x4=非 OFF 档；0x5=热保护；0x6=预留；0x7=Invalid。

远程寻车-闪灯-鸣笛

• 应用场景：地下车库逛完商场找不到车时，从手机 APP 闪灯鸣笛。
• 测试场景：整车电源状态、异常场景（弱网场景）。
• 执行规格：闪灯 6 下、鸣笛 2 声。

远程控制空调

• 空调控制：运行时间不超过 30 分钟；燃油车需启动发动机。
• 相关信号：TBOX_RemoteEngineStartupReq = 0x1（远程启动）、TBOX_RemoteACStartupReq = AC Start（空调开启）、TBOX_RemoteStartRunTime（启动时间）、以及对应的制冷/制热模式、温度。

远程打开空调内部流程：

1. Tbox 发送远程打开空调请求；
2. 前置条件：先向 BMS（电池管理系统）查询剩余电量；
3. 电量低于 10% 直接拒绝打开空调，并有相关提示反馈到手机；
4. 电量充足则执行打开空调操作，向 BCM 发送打开空调信号，BCM 下发信号到空调控制器（空调属于车身域，BCM 就是车身域）；
5. 空调打开后原路返回信息到手机客户端。

远程控制座椅

• 座椅通风加热：主要发送的报文包含通风、加热类型；
• 执行时间：15 分钟内，超过 15 分钟自动停止。

远程车辆查询

• 远程车况查询：车门未关等异常项、车身位置查询、油量/电量/续航里程查询、车门状态、车身状态、车速、电源档位、功率、整车状态。

10.4 公司内部-台架测试流程✓

TBOX 项目人力组成

• 测试人员 3 人左右：APP 测试 1 人；蓝牙测试、远程车控+远程车辆状态 1 人；网络测试、诊断、测试 FOTA 1 人。
• 开发人员：7 个左右。

测试用例与五种模式

• 一般测试用例需要在 Car Mode=Normal、Usage Mode 五种模式下切换测试。
• 五种模式的区别：远程寻车需要在非驾驶状态下发送指令；打开车门需要在待机/舒适/激活状态下发送指令等。
• 车控、远程仪表台及远程车辆状态测试：台架测试（车控用例 200 条左右、远程车辆状态，用例等级 p0-p2）。

TBOX 电流功耗

台架需要使用的设备及工具

TBOX、MCU 串口板、CANalyst（CANoe 替代产品）、以太网小盒、12V 直流稳压电源、USB 线、麦克、喇叭、USB 网络转换器、鳄鱼夹子、T-box 串口线、电源线、Ecall/BCall 按键面板（顶灯）、5G/GPS 天线、备用电池及线材、车身控制器、主机、前排 USB、娱乐显示器、驾驶信息显示屏、副驾屏、网关、蓝牙 NFC、无线充电、NFC 读卡器。

电源管理：唤醒源统计

台架测试流程

1. 搭建台架，确保链路通（DSA 能读取到 TBOX 信息；打开 CANoe 进入 trace 报文界面能看到报文在打印，前提是 CANoe 已创建仿真工程、添加 DBC 文件及车控的 CAPL 脚本）。
2. 五码造车：刚拿到的新 TBOX 五码数据为空，需编辑五码联系对应的人进行造车。五码包括：VIN 码（车辆识别号码，车辆身份证，位于车窗左下角，即车架号）、PDID 码、IMEI 码、ICCID 码、MAC 地址、MSISDN 码。线刷版本后需重新输入 VIN 码和 PDID 码，在工程模式对应模块下手动输入：

vin "LM8C7C594RAS00068" --es pdid "SKEV00050001022024022002200000551"，也可以 UDS 协议中 2E 写入。

1. 绑车：提供自己的手机号绑定为车主账号，即可使用 APP 发送车控指令。
2. TSP 云端网页：登录 TSP 确认车辆是否在线及车况（账号密码由负责云端的开发提供）。
3. 版本下发刷写：开发下发指令给出版本包（文档中版本包）→ 测试人员到公司内网下载对应版本包 → 用类 DSA（吉利）自研工具刷写，添加升级包（一般三个文件：引导文件、测试环境文件、升级包）→ TBOX 升级时间约 7~10 分钟 → 升级完成后先用 22 服务读取版本号和环境是否正确，在 mobax（Linux 系统）用 cat + 路径读取版本确认升级成功。公司有标准流程，测试人员最好做文档记录流程。

TBOX 刷写方法

DSA、USB、Wifi、OTA

1. USB 升级方法：连接 USB，将升级使用的三个文件放入同一文件夹下（mcu_boot.bin、mcu_update.bin 和 update.zip）；
2. 获取 root 权限：adb shell root
3. 进入文件夹：cd C:\Users\wang-qiqi\Desktop\11
4. adb push ./mcu_boot.bin /mnt/sdcard/Update/
5. adb push mcu_update.bin /mnt/sdcard/Update/
6. adb push update.zip /mnt/sdcard/Update/
7. adb push swdl_finish.flag /mnt/sdcard/Update/
8. adb shell → cd /oemdata/Update/ → touch swdl_finish.flag
9. 等待重启则升级完成。
10. WiFi 升级方法：连接 WiFi，将升级文件放在同一文件夹下（mcu_update.bin、update.zip 和 swdl_finish.flag）；
11. scp mcu_update.bin root@192.168.225.1:/oemdata/Update
12. scp update.zip root@192.168.225.1:/oemdata/Update
13. scp swdl_finish.flag root@192.168.225.1:/oemdata/Update
14. 等待重启则升级完成。

车辆配置

用自研工具 car config 做车辆配置，台架上接 PCAN 工具和串口板 E2 烧录，打开串口工具实时打印 MCU log。主要配置车辆信息（工程模式设置对应配置路径，均为配置字）：车辆是混动还是纯电；方向盘在左还是右；车门是直开还是滑动；是否有遮阳帘；是否具有座椅加热、通风、方向盘加热等功能；是否具有香氛功能等。

APP 专享测试

APP 匹配成功以后做专享测试，主要看基本功能是否实现：远程寻车（闪灯、鸣笛、闪灯鸣笛）、车门解闭锁、打开车窗、打开空调、座椅通风、座椅加热、座舱通风等。冒烟通过后开始全功能测试。

远程控制

远控包括哪些功能：

• 远程寻车（闪灯、鸣笛、闪灯鸣笛）；
• 车门解闭锁、打开引擎盖、打开后备箱、打开充电盖；
• 车窗（开度值：全开、全关、半开等）；
• 空调（档位、风速）；
• 座椅通风、座椅加热、方向盘加热、座舱通风（一般等级 1-3）；
• 远程香氛（香氛通道、香氛等级）。

远程车辆状态

• 胎压、温度、剩余电量、续航里程、充电状态、车速、车门车窗空调等状态（刷了新版本后经常出现 BUG）。
• 网络使用：大部分远控走 CAN，部分走以太网；远程车辆状态基本上都走以太网。
• 车门、车锁、车窗等走 CAN，需连接 VGM 网关使用，通过 CANoe 发送信号；
• 胎压、温度、电量、续航里程等走以太网，需连接以太网转换器使用。
• 一次只能发一个信号，先做协议分割确定信号在哪个协议（如电量信号在 0B3 大协议、0000A 小协议），拆分保存 JSON 包，在自研工具中添加 json 文件发送信号指令（以太网 log 抓取也需使用自研工具）；
• 信号发送后可通过 APP 查看结果，或通过 TSP 云端查看返回值记录是否正确。

Log 抓取的步骤

• 单模块抓取：如果只测试一个模块，可单独抓取对应模块 LOG。用 USB 数据线把 TBOX 和电脑连接，抓取命令如：adb pull data/log D:log（台架上 TBOX 也有自己独立的 USB 线）。
• 实车抓取：1. 先车辆上电；2. 连接 adb 后输入命令打开 tbox 的 WiFi；3. 电脑连接 tbox 的 WiFi；4. 连接后通过 adb 命令进入 tbox 后使用 pull 拉出对应日志（tcpdump）。

常见的BUG

（bug 一般有云端的 bug 和 tbox 本身的 bug）

1. 服务订阅成功以后，执行车控指令（如车门解锁）返回执行失败，报 2051（服务未订阅）。
2. 问题分析：需求上一些常用功能如解闭锁是默认订阅的，但由于开发参数问题（底层没有开发到位），导致所有服务都需要手动订阅。
3. 执行车控指令时，结果为 TBOX 执行超时，报 2046（服务期未响应，执行超时）。
4. 问题分析：开发反馈 TSP 云端不稳定（云端开发自身问题），一次指令超时导致 TBOX 卡死（版本系统不稳定，TBOX 系统开发问题）；供应商后台重启 tbox、台架断电重新上电后恢复正常。偶现 BUG，测试时需要 10 次以上复现并跟踪 BUG 版本。网络未通也会反馈服务超时。
5. 发送电量信号成功，但 TSP 显示结果和实际结果不符（如发送电量信号值 500 代表剩余电量 50%，但 TSP 云端实际显示 1000）。
6. 问题分析：开发底层代码有缺陷，后期排查为 tbox 代码逻辑问题，由供应商修复处理。

Bug 的管理

• 首先区分 bug 是必现还是偶现；偶现需备注概率（如 1/3、3/5 等）。bug 严重程度分为 ABCD。
• 必现 bug：开发修复以后，回归 5 次不复现即可关闭。
• 偶现 bug：需跟进 A 级三个版本、B 级 2 个版本、C 级 1 个版本；开发修复后，在验证过程中不复现才可关闭。
• 测试工作：版本升级后验证版本，根据测试用例找到产品缺陷，抓取对应日志及视频，提票到缺陷管理平台指派给对应开发（找不到开发则指派给对应主管，根据人员表格指派）；遇到问题先排查是否是我们自己流程问题造成的链路不同。

E-Call / B-Call / I-Call

• E-Call（紧急呼救）：遭遇紧急情况时，用户按下该键以最高优先级接通呼叫中心（车企呼叫中心），人工坐席将同时获取客户车辆的重要数据并协助驾驶员脱离危险。
• B-call（道路救援）：与 E-call 不同，主要用于非事故情况下的道路救援服务；E-call 通常用于发生严重交通事故等紧急情况下自动或手动拨打紧急呼救电话。

音频策略专项

多路音源混合管理（II 级）：当前音源 E-call，输入音源 B-call 或 I-call。

• 前置：1. 整车上电；2. E-call 呼出 / B-call 呼出。
• 预期：1. 中控屏显示进入 E-call 拨打界面；2. E-call 仍然在拨打界面，不会被 B-call 打断。

10.5 面试问题✓

Q1：Tbox 远程控制的底层链路是什么？

1. 手机端发送远程控制的请求到 TSP 云端服务器；
2. TSP 云端服务器收到请求，根据 VIN 找到对应的车辆；
3. 车辆收到来自服务器的请求，Tbox 跟车内其他 ECU 进行通信，执行相关的操作；
4. 执行完成之后，将结果返回给 TSP 云端，TSP 云端将结果返回给手机端。

Q2：Tbox 在发送相关的信号时，如何看信号传递成功？

发送控制信号时会发送 3 次，确保信号能成功，例如远程空调操作：tbox 被唤醒（有 CAN 报文发出、有日志正常运行）→ TBOX 收到远程启动空调指令（看 log）→ TBOX 发出报文 TBOX_RemoteEngineStartupReq=0x1、TBOX_RemoteStartRunTime 和 TBOX_ACTempValueReq，连续发送 3 帧信号后恢复默认值，确保信号不掉帧。

• 需求定义三帧信号发送（测试用例写三帧）；实际结果要求发送三帧、实际收到两帧：要么是开发少写一帧，要么是 CAN 盒子掉了一帧。