4. ZF线控底盘危害分析与风险评估
危害分析与风险评估（HARA）是ISO 26262功能安全开发流程的起点，也是决定后续安全目标、安全机制与开发投入的“分水岭”。对ZF线控底盘而言，HARA的核心任务不是写一份文档，而是回答三个问题：什么情况下会出危险？危险有多严重？我们能不能在危险发生前把它控制住？这三个问题的答案，最终被压缩成一个ASIL等级，直接决定线控转向、线控制动、线控悬架各子系统需要达到的安全完整性要求。
一、HARA的输入与输出：从“功能”到“安全目标”
HARA的输入是“待分析对象”的功能定义与边界。以ZF线控转向系统（Steer-by-Wire）为例，其核心功能是：根据方向盘转角传感器信号，由转向执行器驱动车轮偏转，同时通过路感电机向驾驶员反馈力矩。分析前必须明确系统的边界——是否包含方向盘执行器、冗余电源、通信总线，以及是否与线控制动、悬架存在协同控制。边界不清，后续的危害识别就会遗漏跨系统耦合风险。
HARA的输出是安全目标（Safety Goal）及其对应的ASIL等级。安全目标是对整车层面危害的顶层安全要求，例如“避免车辆在行驶中发生非预期的转向偏转”。每个安全目标再向下分解为功能安全需求（FSR）和技术安全需求（TSR），最终落到具体的传感器冗余、执行器监控、通信校验等设计上。
二、场景识别：把“功能”放进真实道路
危害不是凭空产生的，它总是发生在特定场景中。场景识别要回答的是：这个功能在哪些工况下可能失效，失效后车辆处于什么状态。对线控底盘，建议从四个维度构建场景矩阵：
- 车辆状态：车速（低速泊车、中速城市、高速巡航）、挡位、是否处于自动驾驶模式。
- 道路环境：直线、弯道、坡道、湿滑路面、车道线清晰度。
- 交通环境：前方有无车辆、行人、对向车流、是否在路口。
- 驾驶员状态：手是否在方向盘上、是否处于接管准备状态、是否分心。
例如，线控转向的“非预期转向”危害，在“高速+弯道+驾驶员手离方向盘”场景下，其暴露度和可控性都与“低速泊车+驾驶员双手握盘”完全不同。场景识别的价值，就是让后续的S/E/C评估有据可依，而不是拍脑袋定级。
三、S/E/C评估：三个维度的判断逻辑
严重度S（Severity）衡量危害对人员伤害的程度，分为S0～S3。S0无伤害，S1轻伤，S2重伤，S3致命。判断依据是碰撞速度、碰撞对象、约束系统是否起作用。线控底盘的非预期转向在高速下可能导致车辆失控并与对向车碰撞，通常评为S3；而在低速泊车时可能只是刮擦，评为S1或S2。
暴露度E（Exposure）衡量场景发生的概率，分为E0～E4。E0极低，E4高概率。注意，E评估的是“场景本身”出现的频率，而不是故障发生的频率。例如“高速弯道行驶”对大多数乘用车而言是E4，“车辆在坡道上起步”可能是E2。ZF线控底盘作为量产乘用车部件，其常见行驶场景的暴露度通常较高。
可控性C（Controllability）衡量驾驶员或其他交通参与者避免伤害的难易程度，分为C0～C3。C0完全可控，C3几乎不可控。可控性评估要结合驾驶员反应时间、车辆动态响应、是否有冗余系统介入。例如，线控制动失效时，若仍有机械备份或电子冗余，驾驶员可通过大力踩踏板实现制动，可控性可评为C1或C2；若完全失去制动能力，则可能为C3。
四、ASIL定级：从S/E/C到安全完整性等级
ASIL等级由S、E、C三者共同决定，分为QM、A、B、C、D五个级别，D为最高。定级规则可概括为：S越高、E越高、C越差，ASIL等级越高。例如S3+E4+C3直接对应ASIL D；S1+E1+C1可能仅为QM或ASIL A。
下面这张图展示了从“功能定义”到“ASIL定级”的完整数据流，以及S/E/C三个参数如何共同作用于安全目标。图中同时标出了线控转向“非预期转向”这一典型危害事件的评估路径，便于对照理解。
五、实战要点：定级不是终点，而是起点
在实际项目中，HARA最容易出现的问题有三个。第一，场景切分过粗，把“高速行驶”笼统当作一个场景，导致E值偏高、ASIL等级虚高，后续开发成本失控。第二，可控性评估过于乐观，默认驾驶员总能及时接管，忽略了线控系统失效时驾驶员可能根本没有足够的反应时间或物理通道。第三，忽略系统间的耦合，线控转向失效可能触发线控制动的协同动作，两个系统的危害事件需要联合评估。
以ZF线控转向的“非预期转向”为例，若评估为ASIL D，则安全目标要求系统在转向执行器失效时，必须在极短时间内进入安全状态——通常是切断该执行器动力、由冗余执行器接管或通过线控制动施加差动制动来稳定车辆。这个安全状态的定义，直接来自HARA中对可控性的判断：如果C3意味着驾驶员无法控制，那么系统必须自己把车稳住。
最后需要强调，HARA不是一次性的文档工作。当线控底盘的功能定义、系统边界、场景假设或法规要求发生变化时，HARA必须重新评估。ASIL等级一旦变化，安全目标、技术方案和验证计划都要同步调整。对功能安全工程师而言，掌握HARA的方法论，比记住某张定级表更重要——因为真实项目中的判断，永远发生在表格之外。