2. ISO 26262在底盘系统中的落地

ISO 26262 不是一张“认证证书”,而是一套贯穿概念、开发、生产、运行到报废的安全工程方法。把它落到制动、转向、悬架这类底盘系统上,核心要回答三个问题:相关项边界怎么划、危害事件的风险等级怎么定、安全活动如何随生命周期逐级展开。这三者相互咬合,任何一环含糊,后续的架构设计、诊断覆盖率和验证深度都会失去依据。

一、相关项定义:先划清“谁在管什么”

相关项(Item)是 ISO 26262 功能安全工作的基本对象,指实现车辆某一功能的系统或系统组合。底盘系统的相关项定义不能简单写成“制动系统”,而要明确功能边界、接口边界和依赖边界。以电子驻车制动 EPB 为例,相关项可定义为“EPB 控制单元、执行卡钳、轮速信号、整车电源与通信接口共同实现的驻车与动态制动功能”,同时明确其与 ESC、整车控制器、网关之间的信号交互。

相关项定义要落到可检查的粒度:功能描述、运行模式、边界接口、外部依赖、法规约束。例如转向系统相关项若包含电动助力转向 EPS,则需说明助力扭矩输出、方向盘扭矩传感器、电机位置信号、整车电源状态以及故障降级策略。边界不清会导致 HARA 中“整车层面危害”与“系统层面失效”混淆,最终 ASIL 分配失去一致性。

二、HARA:从危害事件到 ASIL 等级

危害分析与风险评估(HARA)是确定 ASIL 的核心活动。它先识别功能失效导致的危害事件,再对每个事件从三个维度打分:严重度 S(S0–S3)、暴露率 E(E0–E4)、可控性 C(C0–C3),最后查表得到 QM、ASIL A 到 ASIL D。底盘系统的特殊性在于:制动、转向、悬架直接决定车辆运动状态,S 和 C 往往偏高,因此 ASIL 等级普遍不低。

以制动系统为例,假设某电子制动助力系统在高速行驶时发生“助力完全丢失”失效。严重度可评为 S3(可能造成致命伤害);暴露率取决于该工况出现频率,高速持续行驶可评为 E4;可控性方面,驾驶员仍可通过机械备份或大力踩踏实现部分制动,但反应时间和力度有限,可评为 C2。查表后对应 ASIL D。若同一失效发生在低速泊车工况,E 和 C 下降,ASIL 可能降为 B 或 A。这说明 ASIL 不是系统固有属性,而是危害事件在具体运行场景下的风险等级。

转向系统的典型危害事件是“助力扭矩异常反向”或“助力突然消失”。EPS 在高速下若输出反向扭矩,驾驶员可能来不及修正,C 可评为 C3,S 为 S3,E 为 E4,对应 ASIL D。悬架系统则更多表现为“车身姿态失控”或“阻尼力异常”,例如主动悬架在弯道中错误输出软阻尼,导致侧倾过大,严重度 S2、暴露率 E4、可控性 C2,对应 ASIL B 或 C,具体取决于车速和侧倾阈值。

底盘系统 HARA 与 ASIL 分配关系图 以制动 / 转向 / 悬架典型危害事件为例 相关项定义 制动系统 EPB / ESC / 助力 转向系统 EPS / 线控转向 悬架系统 主动悬架 / CDC 边界要素 功能 / 接口 / 依赖 运行模式 / 法规 HARA 风险评估三维度 严重度 S S0 无伤害 S1 轻伤 S2 重伤 / S3 致命 暴露率 E E0 极低 E1–E3 中低 E4 高频繁 可控性 C C0 完全可控 C1–C2 一般 C3 难以控制 典型危害事件示例 制动助力丢失 · 转向反向助力 · 悬架阻尼异常 高速工况 S3 / E4 / C2–C3 低速泊车 S1–S2 / E2–E3 / C1–C2 ASIL 查表结果(示例) S3 + E4 + C3 → ASIL D S3 + E4 + C2 → ASIL D S2 + E4 + C2 → ASIL B / C 安全生命周期 概念阶段 相关项定义 · HARA · 安全目标 系统开发 技术安全需求 · 架构设计 硬件 / 软件开发 ASIL 分解 · 诊断覆盖 集成与验证 安全确认 · 故障注入 生产与运行 安全档案 · 现场监控 报废与退役 安全信息归档 ASIL 由危害事件在具体运行场景下的 S / E / C 组合决定,并驱动安全生命周期各阶段的活动深度与验证强度

三、安全生命周期:ASIL 如何驱动活动深度

安全生命周期从概念阶段开始,到报废退役结束。ASIL 等级直接决定每个阶段的活动深度。以 ASIL D 的 EPS 为例,概念阶段必须完成相关项定义、HARA、安全目标制定;系统开发阶段要建立技术安全需求,并进行 ASIL 分解。例如将“避免反向助力”这一安全目标分解为“扭矩传感器冗余校验”和“电机输出独立监控”两个子需求,分别分配给不同 ASIL 等级的子模块。

硬件开发阶段,ASIL D 要求更高的诊断覆盖率。以扭矩传感器为例,单通道诊断覆盖率若只能达到 60%,则需采用双通道冗余或增加比较逻辑,使潜伏故障度量满足目标值。软件开发阶段,ASIL D 要求使用形式化方法或严格的静态分析,代码覆盖率需达到语句、分支和 MC/DC 级别。集成与验证阶段,ASIL D 系统必须进行故障注入测试,验证安全机制在真实失效下的响应时间和降级行为。

生产与运行阶段同样受 ASIL 影响。ASIL D 的制动系统需要建立安全档案,记录生产下线检测、现场故障监控和 OTA 更新对安全完整性的影响。若在运行阶段发现新的危害场景,需回溯更新 HARA 和安全目标,形成闭环。

四、底盘三系统的落地差异

制动系统的 ASIL 分配通常最高,因为制动失效直接导致车辆失去减速能力。EPB 的静态驻车功能在坡道场景下若失效,可能造成溜车,严重度 S2、暴露率 E3、可控性 C2,对应 ASIL B;而动态制动助力丢失在高速下可达 ASIL D。转向系统次之,但线控转向由于完全取消机械连接,失效后果更严重,ASIL D 覆盖范围更广。悬架系统相对较低,主动悬架阻尼错误通常不会立即导致致命事故,但若与 ESC 耦合,可能间接影响稳定性,因此需在接口层面明确 ASIL 传递。

实际落地时,建议先建立“危害事件—运行场景—ASIL”对照表,再逐条映射到安全目标和技术安全需求。下表给出一个可参考的示例结构,用于记录底盘系统 HARA 的核心结论。

系统 危害事件 典型场景 S E C ASIL 安全目标示例
制动 助力完全丢失 高速持续行驶 S3 E4 C2 D 避免助力非预期丢失
转向 反向助力扭矩 高速变道 S3 E4 C3 D 避免反向助力输出
悬架 阻尼力异常变软 弯道中高速行驶 S2 E4 C2 B/C 避免侧倾角超限
工程提示:ASIL 分配不是一次性的。当系统架构、运行场景或法规要求发生变化时,必须重新评估 HARA。底盘系统的 ASIL 分解要特别注意“接口传递”——上游 ASIL D 的安全目标分解到下游子模块时,若子模块只按 ASIL B 开发,必须提供独立的安全机制或论证其充分性。

总结来看,ISO 26262 在底盘系统落地的关键路径是:先定义相关项边界,再通过 HARA 确定每个危害事件的 ASIL,最后用安全生命周期把 ASIL 转化为可执行、可验证、可追溯的工程活动。制动、转向、悬架三者的差异不在于方法,而在于危害场景的严重度和可控性不同,导致 ASIL 分布和验证强度不同。理解这一点,才能在具体项目中做出合理的安全决策。