1. Bosch驾驶辅助系统架构总览
Bosch驾驶辅助系统（Driver Assistance System, DAS）并不是单一功能模块，而是一套由感知、决策、执行与通信四层协同构成的实时闭环系统。理解这套架构，是后续进行故障诊断与性能优化的前提。因为绝大多数"功能失效"或"性能下降"的根因，往往并不在功能本身，而在于某一层的信息传递被削弱、被延迟或被误判。
一、四层架构：从环境到动作的完整链路
从工程视角看，Bosch DAS可以拆解为四个相互耦合的层次：
- 传感器层（感知）：负责把物理世界转换为电信号与数据。典型部件包括毫米波雷达（前向长距雷达、角雷达）、单目/双目摄像头、超声波传感器、激光雷达（部分车型），以及用于车身姿态的IMU、轮速传感器和转向角传感器。
- 控制器层（决策）：以域控制器（如Bosch ADCU、MPC2/MPC3等）或独立ECU为核心，完成传感器融合、目标跟踪、场景理解、功能状态机管理与横纵向控制指令生成。
- 执行器层（动作）：包括ESP/ESC（制动）、EPS（转向）、发动机/电机扭矩控制、变速箱控制等，负责把控制指令转化为车辆的实际运动。
- 通信网络层（连接）：以CAN/CAN FD为主干，辅以FlexRay、以太网（车载以太网100BASE-T1/1000BASE-T1）和LIN，承担各层之间的实时数据交换与诊断报文传输。
这四层不是简单的串联，而是带有反馈的闭环：执行器动作会改变车辆状态，车辆状态又会被传感器重新感知，形成持续修正的循环。因此，任何一层的偏差都会在闭环中被放大或掩盖，这也是诊断时需要"看链路"而非"看单点"的原因。
二、通信网络：诊断的"神经系统"
在Bosch DAS中，通信网络既是数据通道，也是诊断入口。以典型配置为例：前向雷达通过CAN FD以约20ms周期发送目标列表；摄像头通过车载以太网发送车道线与交通标志信息；域控制器融合后，以10ms周期向ESP发送加速度请求、向EPS发送转向角请求。诊断仪则通过OBD接口接入CAN，使用UDS（ISO 14229）读取DTC、冻结帧和扩展数据。
这里有一个容易被忽视的要点：通信层的故障往往表现为功能层的"间歇性失效"。例如CAN总线终端电阻异常（标准应为60Ω左右）会导致报文错误帧增加，控制器可能因超时进入降级模式，表现为ACC突然退出而非报出明确的传感器故障。因此，诊断时必须同时观察总线负载率、错误计数器和报文周期抖动。
三、故障诊断与性能优化的整体工作流
结合Bosch工程实践，可将诊断与优化归纳为五个阶段，形成可复用的闭环：
- 症状采集：读取DTC与冻结帧，记录故障发生时的车速、转向角、目标距离等环境参数；同时收集用户对功能表现的描述（如"跟车距离忽远忽近"）。
- 分层定位：依据症状判断问题落在感知、决策、执行还是通信层。例如"车道保持画龙"可能源于摄像头标定偏差（感知）、融合权重不合理（决策）或EPS响应迟滞（执行）。
- 数据验证：使用CANoe/INCA等工具录制原始信号，对比正常工况与故障工况下的目标ID、距离、相对速度、置信度等参数，确认偏差出现的具体环节。
- 优化调整：针对根因调整参数或策略，如重新标定摄像头外参、修正雷达安装角度、调整融合滤波系数或控制增益。
- 回归验证：在封闭场地或指定路试路线复现原工况，确认故障消除且未引入新的降级或误触发。
四、架构视角下的诊断思维
把DAS当作闭环系统来看，诊断的本质是沿信号链定位偏差来源：从物理量（距离、角度）到电信号，到数据报文，到融合结果，到控制指令，再到车辆运动。每一段都有可观测的中间量。例如，当AEB未触发时，可以依次检查：雷达是否检测到目标（原始目标列表）、融合后目标是否存在且置信度足够、TTC计算是否正确、制动请求是否发出、ESP是否执行。只要中间量可观测，故障点就能被逐段收敛。