1. 课程导入与工程对象界定
在整车电子电气架构从分布式 ECU 向“中央计算 + 区域控制”演进的过程中，车身域控制器（Body Domain Controller，BDC）成为承载车门、车窗、灯光、雨刮、座椅、尾门、无钥匙进入等车身舒适与安全功能的核心节点。Continental（大陆）作为全球主流 Tier1，其车身域控制器软件平台并非单一产品，而是一套可跨车型复用的基础软件 + 应用框架 + 配置工具链的组合。本课程讨论的对象，是运行在 Continental 车身域控制器硬件之上的软件平台工程，包括 AUTOSAR 基础软件、车身应用组件、诊断与刷写、网络管理与电源管理，以及支撑这些内容的配置、集成与验证方法。
需要先界定边界。车身域控制器软件平台不包含：具体车型的整车网络拓扑设计、线束与接插件定义、硬件 PCB 设计、以及上层座舱娱乐或自动驾驶算法。它包含：AUTOSAR Classic Platform 的 MCAL、ECU 抽象层、服务层、RTE，车身功能的应用软件组件（SWC），诊断栈（UDS/OBD），网络管理（NM），以及基于配置文件的代码生成与集成流程。理解这条边界，才能避免把“域控软件平台”与“整车电子架构”混为一谈。
典型车型应用可以按平台代际理解。早期分布式架构中，车身功能分散在 BCM、门模块、座椅模块等多个 ECU；进入域集中阶段后，Continental 的 BDC 通常覆盖以下功能域：进入与启动（PEPS、无钥匙进入、防盗）、门窗与尾门（防夹、儿童锁、电动尾门）、灯光（内外灯、转向、日行灯、氛围灯）、雨刮与清洗、座椅与后视镜、电源与网络管理。这些功能在同一域控内通过 SWC 划分，共享基础软件与通信栈。典型应用车型包括大众 MQB/MEB 平台、宝马部分车型、以及国内多家主机厂的中高端车型；不同车型的差异主要体现在配置参数、信号矩阵和功能变体上，而非软件平台本身。
开发流程总览可以按 V 模型展开，但工程上更值得关注的是配置驱动这一特征。车身域控软件平台的开发不是从零写代码，而是：先获取整车信号矩阵与功能需求，再在配置工具中定义 ECU 配置、SWC 端口、RTE 连接、诊断参数、网络管理参数，然后由工具链生成基础软件与 RTE 代码，最后与应用层代码一起编译、刷写、测试。这个流程决定了工程师的核心能力是读懂配置、定位配置与代码的对应关系、以及验证配置结果。
学习路径建议按“先结构、后配置、再验证”推进。第一阶段建立分层认知：能说清 MCAL、ECU 抽象、服务层、RTE、SWC 各自负责什么，以及一个车门控制信号从 LIN 从节点到应用层状态机再到执行器输出的完整路径。第二阶段进入配置实践：以一份简化的车门控制配置为例，理解 ARXML 中 SWC 端口、RTE 连接、COM 信号、DTC 定义之间的对应关系。第三阶段做验证：用 CANoe 或类似工具观察报文、诊断响应和功能状态，判断配置是否生效。
为了便于后续章节对照，这里给出一份工程对象界定检查表，用于判断一个具体任务是否属于本课程范围：
| 检查项 | 属于本课程范围 | 不属于本课程范围 |
|---|---|---|
| 软件层次 | AUTOSAR BSW、RTE、车身 SWC、诊断栈、NM | 座舱娱乐、自动驾驶算法、云端服务 |
| 配置对象 | ECU 配置、SWC 端口、RTE 连接、DTC/DID、变体码 | 整车网络拓扑、线束定义、PCB 布局 |
| 工具链 | 配置工具、代码生成、编译集成、刷写工具 | 需求管理平台、项目管理工具 |
| 验证手段 | CANoe 报文分析、UDS 诊断、HIL 功能测试 | 整车道路试验、碰撞安全测试 |
| 交付物 | 生成代码、HEX/S19、A2L、配置追溯表 | 整车合格证、法规认证文件 |
最后强调一个工程习惯：车身域控软件平台的问题，大多数不是“代码写错了”，而是“配置与需求不一致”。例如车门防夹功能失效，可能不是算法问题，而是 LIN 从节点信号未正确映射到 SWC 端口，或 RTE 连接缺失。因此，本课程后续每一章都会尽量落到“配置在哪里、怎么改、改完怎么验证”这三个问题上，而不是停留在概念介绍。