2. 车规ECU产品形态与系统边界
在整车电子电气架构中，ECU（Electronic Control Unit，电子控制单元）并不是一个抽象概念，而是以“壳体+PCB+连接器+软件+标定数据”的实体形态存在。理解 Continental 这类 Tier1 的产品线，关键不是记住型号，而是看清每个 ECU 在整车架构中的位置、它负责的物理对象、它对外暴露的接口，以及它与上下游之间的责任边界。本章围绕产品线、架构位置、系统边界与接口协作展开。
2.1 Continental 典型 ECU 产品线
Continental 的 ECU 产品线通常按整车功能域划分，常见四类：
- 车身域（Body）：如 BCM（Body Control Module）、车门模块、座椅模块、雨量/光照传感器接口。主要处理低速开关量、LIN 从节点、CAN 舒适报文，控制灯光、雨刮、门锁、车窗等。典型工作电压 9–16V，休眠电流要求常在 100µA 量级。
- 动力域（Powertrain）：如发动机控制器 EMS、变速箱控制器 TCU、混动控制器 HCU。对实时性、喷油/点火时序、扭矩精度要求极高，常带 CAN FD、FlexRay 或以太网，并需满足 ASIL C/D 功能安全等级。
- 底盘域（Chassis）：如 ESC/ABS、EPS、空气悬架 ECU。直接关系车辆稳定性，通常要求 ASIL D，接口上大量使用私有 CAN、PSI5 或传感器专用链路，对时延和冗余有硬性约束。
- 域控制器/中央计算（Domain/Zone Controller）：如车身域控、智能座舱域控、自动驾驶域控。它们不再只控制单一执行器，而是汇聚多路 CAN/LIN/以太网，运行 SOA 服务，承担跨域协调与 OTA 升级。
这四类产品在开发流程上共享同一套需求到量产的 V 模型，但边界划分、接口数量和验证重点差异很大。车身域偏“多而慢”，动力底盘偏“少而快且安全”，域控偏“集成与算力”。
2.2 ECU 在整车 E/E 架构中的位置
从整车视角看，ECU 位于“传感器/执行器”与“整车网络/云端”之间。以车身域为例：门把手开关、雨量传感器是输入；门锁电机、车窗电机是输出；BCM 采集输入、执行逻辑、驱动输出，并通过 CAN 向仪表、网关上报状态。网关再把跨域报文转发给动力或底盘域。域控制器出现后，部分原本分散的 ECU 功能被上收，但物理执行器仍留在本地，形成“中央计算+区域控制+末端执行”的三层结构。
2.3 系统边界划分：什么在 ECU 内，什么在 ECU 外
系统边界不是画在壳体上的线，而是责任与接口的切分。以 BCM 为例，边界内通常包括：输入信号采集与去抖、控制逻辑与状态机、输出驱动与故障诊断、网络报文收发与超时监控、电源模式与休眠唤醒。边界外则包括：传感器/执行器本身、网关路由、整车厂的功能需求与标定规范、芯片与连接器供应商、产线 EOL 测试与刷写。
边界划分的核心判断依据有三条：物理归属（信号从哪来、到哪去）、实时性归属（谁必须在多少毫秒内响应）、安全归属（失效后果由谁承担）。例如，车窗防夹的电流采样必须在 BCM 内部完成，因为响应时间要求小于 10ms；而车窗开关的物理位置在车门，属于边界外输入。再如，OTA 升级包的解压与校验放在域控制器，BCM 只接收刷写指令并进入 Bootloader，这是典型的边界切分。
2.4 接口定义与上下游协作
ECU 的接口分为四类：电源接口（KL30 常电、KL15 点火、接地）、通信接口（CAN/CAN FD、LIN、以太网、FlexRay）、输入输出接口（数字量、模拟量、PWM、高边/低边驱动）、诊断与标定接口（UDS over CAN、XCP、DoIP）。每类接口都需要在需求阶段定义清楚电气参数、报文矩阵、诊断服务和时序约束。
上下游协作关系可以概括为：整车厂给出功能需求与整车网络拓扑；Tier1 完成 ECU 硬件、基础软件、应用软件与标定；芯片供应商提供 MCU、收发器、驱动芯片；工具链供应商提供编译、标定、诊断工具；产线完成 EOL 测试与追溯。以 CAN 报文为例，整车厂定义报文 ID、周期、信号布局；Tier1 实现发送/接收、超时监控与故障降级；网关负责跨域路由；诊断仪通过 UDS 读取 DTC。任何一方变更接口，都必须走变更管理流程，否则会出现“报文对不上、诊断进不去、刷写失败”的典型问题。
2.5 从产品形态到量产的关键检查点
当产品形态和边界确定后，进入量产前需要重点检查：连接器针脚定义是否与整车线束一致；CAN 终端电阻与拓扑是否匹配；休眠电流是否满足整车静态电流预算；诊断服务是否覆盖所有 DTC 与刷写流程；EOL 测试项是否覆盖全部输入输出通道。这些检查点直接决定 ECU 能否顺利装车并稳定运行。理解产品线、架构位置、边界与接口，是后续需求分析、软件开发和测试验证的共同基础。