1. ADAS域控网络与诊断工程导入

ADAS域控制器不是一颗“更快的ECU”，而是一台把感知、融合、决策、执行与整车网络连接在一起的嵌入式计算平台。Bosch在乘用车ADAS/AD域控上的典型形态，通常围绕一颗高算力SoC（如英飞凌、瑞萨、TI或NVIDIA方案）构建，外围挂载以太网交换机、CAN/CAN FD收发器、LIN、FlexRay（部分平台）、IMU、摄像头SerDes解串器、雷达与激光雷达接口，并通过网关与整车其他域通信。理解这套架构，是后续网络与诊断工程的前提。

从工程视角看，ADAS域控的网络与诊断工作可以拆成三条主线：通信链路（物理层、数据链路层、协议栈、时间同步）、诊断服务（UDS、DoIP、DTC、刷写、标定）、整车集成（网关路由、网络管理、功能安全与信息安全约束）。这三条主线并非并列，而是相互耦合：例如DoIP刷写依赖以太网链路与TCP/IP栈，DTC上报依赖CAN/以太网信号与诊断事件管理，时间同步又直接影响多传感器融合与诊断时间戳的一致性。

典型架构：从传感器到执行器的信号链

Bosch ADAS域控的典型拓扑可以抽象为“感知输入—域控计算—执行输出—诊断与刷写通道”四段。感知侧，前视摄像头通过GMSL/FPD-Link SerDes进入域控，毫米波雷达通过CAN FD或以太网输出目标列表，激光雷达通过以太网输出点云；域控内部，SoC运行感知与融合算法，MCU负责安全监控、网络管理与诊断；执行侧，域控通过CAN FD向EPS、ESP、VCU发送横向/纵向控制请求；诊断侧，OBD接口经网关路由到域控，或通过DoIP直接访问以太网诊断端口。

网络与诊断工程的核心任务

网络工程的核心任务，是保证“信号在正确的时间、以正确的格式、到达正确的位置”。具体包括：通信矩阵设计（报文ID、周期、信号布局、超时策略）、协议栈配置（CAN FD波特率与采样点、以太网VLAN与TSN调度、SOME/IP服务发现）、时间同步（gPTP/802.1AS，确保多传感器时间戳对齐）、网络管理与唤醒（NM报文、部分网络、休眠唤醒策略）。诊断工程的核心任务，则是保证“故障可发现、可定位、可修复、可升级”。具体包括：UDS服务实现（0x10会话控制、0x22读数据、0x2E写数据、0x19读DTC、0x31例程控制、0x34-0x37刷写）、DoIP配置（逻辑地址、激活线、路由激活）、DTC事件管理与快照/扩展数据、刷写流程与回滚策略、OTA差分升级与安全校验。

两者在工程上必须协同：例如刷写时需要通过诊断会话切换到编程会话，同时网络管理要保证刷写期间不进入休眠；DTC上报时需要通过通信矩阵确认信号有效性，避免误报。这种协同关系，是ADAS域控网络与诊断工程区别于传统ECU开发的关键。

学习路径与实战目标

本课程的学习路径按“先通链路、再通服务、后通集成”组织。第一阶段建立网络基础：CAN/CAN FD帧结构、以太网帧与VLAN、SOME/IP与DoIP协议栈、gPTP时间同步；第二阶段深入诊断：UDS服务集、DTC机制、刷写流程、诊断数据库（ODX/CDD）与诊断描述；第三阶段进入集成与实战：网关路由配置、网络管理策略、功能安全与信息安全约束、OTA升级链路、典型故障排查。

实战目标可以具体化为：能够独立阅读并修改通信矩阵DBC/ARXML；能够用CANoe/CANalyzer或Wireshark抓取并解析CAN FD与DoIP报文；能够编写UDS诊断脚本完成会话切换、DTC读取与清除、数据读写；能够配置DoIP路由激活并完成一次完整的刷写流程；能够根据DTC快照与总线日志定位通信超时、信号无效、刷写失败等典型问题。这些目标不是理论背诵，而是可操作、可验证的工程能力。

关键参数与观察点示例

以下参数为教学示例，用于说明工程中需要关注的典型配置项，并非某车型实测值。CAN FD常用仲裁段500 kbps、数据段2 Mbps，采样点建议仲裁段75%~80%、数据段70%~75%；以太网100BASE-T1常用100 Mbps全双工，VLAN ID需与整车网络规划一致；DoIP逻辑地址通常由OEM分配，例如诊断仪0x0E00、域控0x0E01，路由激活需匹配激活线类型与TLS策略。观察点包括：总线负载率是否超过60%、报文周期抖动是否在±10%以内、DTC状态位（testFailed、confirmedDTC、pendingDTC）变化是否符合预期、刷写时Erase/Write/Verify各阶段耗时与重试次数。

这张表不是背诵清单，而是你进入每个实验前的检查框架。真正动手时，你会发现“输入”往往来自多个文档，“观察点”需要工具配合，“判断依据”则依赖你对整车网络与诊断规范的理解。这正是本课程要训练的核心能力：把分散的协议、参数、工具和现象，串成一条可验证的工程链路。