1. 课程导入与TRAVEO T2G家族全景

车身控制器（BCM）是整车电子电气架构中最贴近用户感知的节点之一：它要管理车灯、雨刮、门锁、车窗、座椅、后视镜、无钥匙进入与启动、LIN 子节点等大量低速负载，同时又要通过 CAN/CAN FD 与网关、动力、座舱域交互。这类控制器的典型特征是"IO 多、通信接口杂、低功耗要求严、功能安全与信息安全要求逐步抬升"，而算力需求又远低于座舱或智驾域。英飞凌 TRAVEO™ T2G 系列正是针对这一区间设计的车规级微控制器家族，理解它的家族划分与选型逻辑，是后续所有驱动开发、AUTOSAR 配置与整车集成工作的起点。

一、TRAVEO T2G 在整车 EE 架构中的定位

当前主流整车电子电气架构正从"分布式 ECU"向"域集中 + 区域集中"演进。在分布式阶段，每个车身功能可能对应一个独立 ECU；在域集中阶段，车身域控制器（BDC/Body Domain Controller）统一接管原本分散的车身负载；在区域架构（Zonal）阶段，控制器按物理位置划分，车身域功能被拆分到前/后/左/右区域控制器中，通过中央计算单元协同。TRAVEO T2G 在这三种形态中都有落点：既可以做单一功能 BCM，也可以做车身域主控，还可以作为区域控制器中的实时执行层 MCU。

它的核心价值在于"接口密度"而非"算力峰值"。以典型车身域控制器为例，一颗 T2G 器件往往需要同时驱动几十路高低边开关、多路 LIN 主节点、若干路 CAN FD、以及大量模拟采样通道，还要在休眠状态下把静态电流压到微安级。这种"多接口 + 低功耗 + 车规可靠"的组合，正是 T2G 家族的设计重心。

二、家族划分：从入门到高性能的连续覆盖

TRAVEO T2G 家族按内核、主频、存储、外设规模形成连续梯度，主要可分为几个层次：

• 入门级（如 CYT1 系列）：单核 Arm® Cortex®-M0+，主频约 48 MHz，Flash 从 64 KB 到 256 KB，适合简单 LIN 从节点、小型执行器控制、低成本车身子模块。
• 主流级（如 CYT2 系列）：Cortex-M4F 单核或 M4F+M0+ 双核，主频约 80～160 MHz，Flash 从 256 KB 到 2 MB 以上，集成 CAN FD、LIN、CXPI、Segment LCD、CapSense 等车身常用外设，是 BCM 与车身域控制器的主力选择。
• 高性能级（如 CYT3/CYT4 系列）：Cortex-M7 单核或 M7+M4 双核，主频可达 240～350 MHz，Flash 可达 4 MB 以上，带以太网、硬件安全模块（HSM）、更高等级功能安全支持，适合车身域主控、网关融合、区域控制器等场景。

需要强调的是，家族内不同型号并非简单"放大缩小"，而是在外设组合、安全等级、封装引脚数、温度等级上做了差异化。选型时不能只看主频和 Flash，必须把"接口清单"和"安全/功耗要求"放在同等位置。

三、选型依据：从需求到型号的映射

实际选型通常按以下顺序收敛，而不是先挑型号再想功能：

1. 梳理负载与接口清单：统计高边/低边通道数、LIN 主/从节点数、CAN/CAN FD 路数、模拟输入路数、是否需要以太网、是否需要 Segment LCD 或触摸按键。
2. 确定通信矩阵：车身域通常需要 2～4 路 CAN FD 与网关交互，LIN 节点可能多达 10 路以上，若涉及区域架构还需评估以太网或 CAN XL 的预留。
3. 评估算力与存储：AUTOSAR CP 栈本身会占用数百 KB Flash 与数十 KB RAM，加上应用逻辑、诊断、OTA 双区备份，Flash 需求往往比裸机项目高出一倍以上。
4. 确认功能安全与信息安全等级：涉及门锁、启动、灯光等安全相关功能时，需评估 ASIL-B 及以上的支持能力；涉及 OTA 与诊断访问时，需确认 HSM/SHE 支持。
5. 核对功耗与封装：休眠电流目标、唤醒源数量、PCB 面积与引脚数共同决定最终封装与型号后缀。

四、典型车身域应用场景

TRAVEO T2G 在车身域的应用可以归纳为四类：

• 车身控制模块（BCM）：车灯、雨刮、门锁、车窗、后视镜控制，通常以 CYT2 系列为主，配合 LIN 驱动车门/后视镜子节点。
• 车身域控制器（BDC）：集中管理多个车身功能，需要更多 CAN FD 与更高算力，倾向 CYT3/CYT4。
• 区域控制器（Zonal Controller）：按物理区域布置，承担本区域 IO 汇聚与实时执行，强调接口密度与低功耗。
• 智能执行器与子节点：如电动尾门、座椅模块、氛围灯控制器，常用 CYT1 或 CYT2 入门型号。

五、架构演进对软件开发的影响

架构演进直接改变软件形态。分布式阶段，软件以裸机或小 RTOS 为主，功能边界清晰；域集中阶段，AUTOSAR CP 成为主流，需要处理多核分配、复杂诊断、OTA 与信息安全；区域架构阶段，软件进一步要求"服务化"与"跨域协同"，MCU 侧需要更强的通信抽象与时间同步能力。这意味着学习 TRAVEO T2G 不能只停留在寄存器操作，还要理解它在 AUTOSAR 分层中的位置、MCAL 配置逻辑以及与整车网络的交互方式。

六、从选型到开发的衔接

选定型号之后，开发工作会沿着"硬件抽象—外设驱动—通信栈—应用逻辑—整车集成"逐层展开。以 CYT2 系列做 BCM 为例，典型工作包括：基于 ModusToolbox™ 或 AUTOSAR 工具链建立工程，配置系统时钟与电源模式，初始化 CAN FD 与 LIN 驱动，实现高低边开关的 PWM 与诊断反馈，接入休眠唤醒管理，最后通过 CANoe/CANalyzer 与整车网络联调。这些内容将在后续章节逐一展开。

本节的核心结论可以概括为三点：第一，TRAVEO T2G 的定位是"接口密集、低功耗、车规可靠"的车身与区域控制 MCU，而非算力型器件；第二，家族从 CYT1 到 CYT4 形成连续梯度，选型必须从接口清单、通信矩阵、算力存储、安全等级、功耗封装五个维度收敛；第三，EE 架构从分布式走向域集中与区域集中，直接决定了软件从裸机走向 AUTOSAR CP 乃至服务化，这是后续所有开发工作的背景约束。