4. 系统需求分析与功能安全

车辆运动控制系统的开发起点并不是某个ECU或某条控制算法，而是整车级的需求。整车级需求描述的是“车辆应该表现出什么行为”，例如在低附着路面上制动时保持方向稳定性、在紧急避障时响应驾驶员转向意图、在驱动防滑时限制车轮滑移。这些需求经过逐层分解，最终落到Bosch控制功能需求上，例如ESP的横摆角速度闭环控制、TCS的驱动滑移控制、VDC的车辆姿态干预。需求分解的核心挑战在于：整车级指标往往是主观的、综合的，而控制功能需求必须是可测量、可验证、可分配的。

以“制动时保持方向稳定性”为例，整车级需求可以量化为：在附着系数0.3的对开路面以80 km/h制动，车辆横摆角速度偏差不超过±4 °/s，车道偏移不超过0.5 m。这个指标不能直接交给某一个控制器，而需要分解为：轮速传感器精度需求、横摆角速度传感器量程与零偏需求、液压执行器建压响应时间需求、ESP控制周期与算法鲁棒性需求。分解过程中必须明确每一项需求的来源、分配对象和验证方法，否则后续标定将失去判据。

在Bosch的开发体系中，需求通常以功能网络的形式组织。以ESP为例，其功能需求包括：监测驾驶员制动请求、估算车辆参考横摆角速度、计算目标横摆力矩、分配单轮制动压力、监控系统可用性。这些功能需求之间不是简单的串联，而是存在信号交互与优先级仲裁。例如当ABS激活时，ESP的横摆控制需要与ABS的滑移控制协调，避免执行器冲突。因此，需求分析不仅要写清楚“做什么”，还要写清楚“在什么条件下做、与谁协调、冲突时谁优先”。

ISO 26262对功能安全的定义是：不存在由电子电气系统的功能异常表现引起的危害而导致的不合理风险。对于车辆运动控制系统，功能安全的核心工作是识别危害事件、评估风险等级、设计安全机制。危害事件通常从整车行为出发，例如“非预期制动”“非预期加速”“横摆控制误干预”。每个危害事件需要评估三个维度：严重度S（伤害程度）、暴露率E（场景发生概率）、可控性C（驾驶员能否控制）。三者组合决定ASIL等级，从QM到ASIL D。

以“ESP非预期单轮制动”为例。严重度S：在高速行驶时可能导致车辆突然偏转，可能造成严重伤害，取S3。暴露率E：车辆在高速公路上行驶的时间占比较高，取E4。可控性C：普通驾驶员面对突然的单轮制动很难及时纠正，取C3。查表可得ASIL D。这意味着该危害对应的安全目标必须是最高等级，安全机制需要具备高诊断覆盖率。相反，“ESP指示灯显示错误”只影响驾驶员信息，严重度低、可控性高，通常为QM或ASIL A。

安全机制的设计需要与ASIL等级匹配。对于ASIL D的横摆角速度信号，常见的安全机制包括：传感器信号范围检查、信号梯度检查、与轮速差和横向加速度的合理性校验、双传感器冗余或自校验。对于ASIL C的制动压力控制，需要监控压力传感器是否卡滞、执行器是否响应、建压是否超时。对于ASIL B的轮速信号，需要检测信号丢失、齿圈故障和电磁干扰。安全机制不是越多越好，而是要与危害分析和风险评估的结果对应，避免过度设计导致成本和复杂度失控。

从整车级需求到Bosch控制功能需求，最终还要落到标定参数上。例如，横摆角速度偏差阈值±4 °/s对应到ESP控制功能中，可能体现为目标横摆角速度与实际横摆角速度的偏差死区参数、PID控制器的比例增益、单轮制动压力的上升斜率限制。这些参数在标定过程中需要反复调整，但调整范围必须受安全需求约束。例如，如果为了提升响应速度而增大比例增益，可能导致系统在低附着路面上超调，进而违反方向稳定性需求。因此，标定工程师必须理解每个参数背后的安全需求来源，而不是只关注车辆主观评价。

在实际工程中，需求分析与功能安全不是一次性完成的，而是迭代进行的。当标定发现某项需求无法满足时，可能需要回到系统级需求重新分配，例如提高传感器精度、缩短控制周期或调整执行器响应。当安全分析发现新的危害事件时，也可能需要增加安全机制或提高ASIL等级。整个过程中，需求追溯矩阵是保持一致性的关键工具。它记录了从整车级需求到软件需求、再到标定参数的完整链路，确保任何变更都能被评估影响范围。

总结来说，本节的核心是建立一条从整车行为到控制功能、再到安全机制和标定参数的完整链路。整车级需求回答“车辆应该怎样”，系统级需求回答“系统需要具备什么能力”，控制功能需求回答“控制器具体做什么”，安全机制回答“如何防止功能异常导致危害”，标定参数回答“如何让功能在真实车辆上达到预期表现”。只有这条链路清晰、可追溯、可验证，车辆运动控制系统的开发才能既满足性能要求，又满足功能安全要求。