您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



文章 咨询 工具 课程  
会员   
   
AI智能体开发技术实践
线上 10月22-23日
OCSMP 认证培训
10月23-24日 北京+线上
AI时代的需求分析师培养
10月20-21日 北京+线上
     
   
 订阅
主动悬架到底是什么ASIL?从HARA到失效降级的完整拆解
 
作者:兰花雅竺
 
  32   次浏览      4 次
 2026-10-9
 
编辑推荐:
本文主要介绍了主动悬架ASIL不是产品标签。本文从Item边界、危险事件、安全状态、双通道与验证闭环拆解正确方法。希望对你的学习有帮助。
本文来自于微信公众号E车人,由火龙果软件Alice编辑,推荐。

摘要:主动悬架ASIL不是产品标签。本文从Item边界、危险事件、安全状态、双通道与验证闭环拆解正确方法。

图 1 主动悬架功能安全工程封面

主动悬架正在从舒适配置变成底盘核心执行系统。半主动减振器只能调节能量耗散,全主动悬架却可以依靠液压泵、电机或电液作动器,主动推拉单个车轮,改变车身高度、俯仰、侧倾与轮胎载荷。能力边界一旦扩大,故障能造成的车辆响应也会完全不同。

于是项目会上经常出现一个看似直接的问题:主动悬架究竟是 ASIL B、ASIL C,还是 ASIL D?有人根据执行器功率判断,有人看供应商芯片能支持到什么等级,还有人因为它会影响操稳,直接把整个系统写成 ASIL D。

这些说法都跳过了 ISO 26262 的起点。汽车安全完整性等级(ASIL, Automotive Safety Integrity Level)不是给某类产品贴的固定标签,而是危险事件经过严重度(Severity)、暴露概率(Exposure)和可控性(Controllability)评估后的结果。真正继承 ASIL 的首先是安全目标,随后才是由安全目标分解出来的功能、技术、硬件和软件安全要求。

因此,主动悬架功能安全的正确问题不是“它是什么 ASIL”,而是“哪个失效行为,在什么运行场景中,会产生什么车辆危害,人或自动驾驶系统还能否及时控制”。本文就沿着这条链路,把 Item Definition、HARA、安全目标、降级架构和验证证据串起来。

图 2 主动悬架ASIL判断方法

一、先给结论:主动悬架没有唯一ASIL

同一套主动悬架硬件,可以承载不同安全等级的功能。舒适模式下的小幅阻尼调整失效,可能只造成乘坐体验下降;高速弯道中某一车轮突然抬升,可能引入附加横摆或侧倾力矩;车辆举升维修时的非预期下降,又是另一类运行场景和伤害路径。它们不能共用一句“主动悬架故障”。

ASIL 判断对象是危险事件,即危险与运行场景的组合。失去主动抑制侧倾、错误输出单角垂向力、四角高度指令冻结、执行器持续向一个方向作动,看起来都属于悬架故障,但车辆效应、暴露概率和可控性并不相同。

英飞凌 2025 年公开了一份以主动悬架为例的功能安全应用笔记。资料中的一个示例是:自动驾驶车辆在发卡弯内发生非预期单角高度变化,可能诱发横摆或侧倾,示例用 S3、E3、C3 得到 ASIL C。资料同时明确,这只是用于说明安全生命周期的示例,不覆盖全部架构、危险和设计选择。

这个案例最有价值的地方不是“主动悬架等于 ASIL C”,而是证明评级必须绑定功能、车辆模式和场景。换一辆车、换一种作动能力、换一个运行域,S/E/C 都可能变化。量产项目必须重新完成整车级 HARA,不能照抄供应商案例。

二、Item边界不清,后面的HARA都会漂

ISO 26262-3 的概念阶段从 Item Definition 开始。对于主动悬架,Item 不能只写成“四个作动器加一个 ECU”。至少要说明机械弹簧和减振器是否能在失电后独立承载车身,四角执行器由谁供电和驱动,上层目标来自独立悬架控制器还是底盘域控,以及 ESC、制动、转向、动力和车身控制器提供哪些信号或承担哪些降级责任。

还要先区分半主动与全主动。连续可变阻尼通常只能改变阻尼力,失电后可通过阀系落到预定义阻尼特性;全主动系统能够向悬架注入能量,主动改变车轮或车身运动,其错误作动可能比单纯“失去舒适功能”更危险。若两者在 Item 中混成一个“智能悬架”,危险分析就会把完全不同的能量边界揉在一起。

典型边界包括四个角模块、位置或行程传感器、车身与车轮加速度传感器、控制器、功率驱动、低压或高压供电、车载通信、机械回退结构和热管理。外部接口则包括车速、方向盘转角、横摆率、制动请求、驱动扭矩、道路预瞄、驾驶模式和车辆状态。

边界还要回答“谁保证车辆稳定”。如果主动悬架退出后由 ESC、制动或转向系统帮助维持车辆状态,那么这些跨域交互不是一句“由整车负责”就能带过,而应成为明确的接口假设、功能安全要求和验证对象。

图 3 主动悬架Item边界

三、从故障到伤害,中间至少隔着五层

功能安全分析最常见的误区,是把零部件故障直接等同于人员伤害。例如“高度传感器断线导致翻车”省略了大部分工程推理。更完整的链路应是:故障源造成内部错误,错误传播为 Item 失效行为,失效行为在特定场景下形成车辆危害,车辆危害最终才可能造成人员伤害。

以左前高度传感器偏置为例。传感器偏置本身只是故障;如果控制器没有发现,可能产生错误的左前作动力;当车辆处于高速弯道或紧急变道时,这个非对称垂向力可能改变轮胎法向载荷并叠加横摆、侧倾响应;只有在驾驶员或自动驾驶控制无法及时补偿时,才可能演变为失稳和碰撞风险。

因此,危险分析应从失效行为出发,至少覆盖“功能丢失、部分或间歇功能、功能过度、功能错误、非预期功能”这些方向。主动悬架尤其要关注非对称性,因为同样大小的四角同步高度偏差和单角突变,对整车运动的影响完全不同。

另一个容易遗漏的对象是过渡过程。系统从主动模式切到被动模式,最终稳态也许安全,但如果四个角卸载不同步、阀门切换过快、车身姿态瞬间跳变,危险可能发生在几百毫秒到数秒的过渡窗口,而不是故障后的最终状态。

图 4 主动悬架故障到危害链

四、HARA不是填表,而是把场景拆到足够具体

严重度评估的是潜在伤害,不是零件损坏程度;暴露概率评估车辆处于相关运行场景的频率,不是电子元件的失效率;可控性关注相关人员能否通过及时反应避免伤害,也不能简单用“驾驶员会接管”代替证据。

同一个“非预期单角抬升”,放在停车场低速挪车、城市直行、高速弯道和紧急避障中,会得到不同结果。车辆速度、横向加速度、路面附着、载荷、自动驾驶状态、驾驶员是否握持方向盘,都会改变 S/E/C。

可控性尤其容易被高估。故障若产生突然的横摆或侧倾力矩,驾驶员先要感知异常,再完成判断、转向或制动,车辆还要等待执行器建立响应。若系统用于高阶自动驾驶,驾驶员可能并不处于可立即干预的状态。此时不能沿用传统有人驾驶车型的可控性假设。

HARA 也不应只分析“最大功率输出”。卡滞在某一高度、单角缓慢漂移、四角命令符号相反、通信冻结为旧值、模式切换时状态不同步,都可能比简单断电更隐蔽。工程上应把幅值、方向、持续时间、变化率和对称性作为失效行为参数。

图 5 主动悬架HARA的SEC判断

五、公开ASIL C示例,应该怎样正确使用

英飞凌主动悬架应用笔记给出的示例值得拆开看。其 Item 环境包含四个主动悬架角模块、供电、通信和 ESC;危险场景是自动驾驶车辆在发卡弯中发生非预期轮高变化;潜在车辆危害是横摆或侧倾导致稳定性丢失;该示例最终得到 ASIL C,并形成“防止因悬架故障导致车辆稳定性丢失”的安全目标。

这个示例可以用来检查自己的分析逻辑,却不能直接复制评级。首先,示例假设自动驾驶系统无法像传统驾驶员那样及时反打方向或制动,可控性判断带有明确的车辆模式前提。其次,发卡弯的出现频率、车辆速度和作动器能力会影响暴露与危害。再次,不同机械回退结构会改变故障后车辆响应。

一个成熟的项目应建立危险事件矩阵,而不是只保留最高等级那一行。矩阵需要覆盖正常驾驶、低速、停车、举升、拖车、诊断、生产下线和维修等模式,并标明功能是否激活、执行器是否有能量、人员处于什么位置。

当多个危险事件汇聚到同一个安全目标时,安全目标通常继承其中最高的 ASIL。但这并不意味着 Item 内所有软件、传感器和通信都必须机械地使用同一等级。后续可以通过需求分配、独立安全机制或满足条件的 ASIL 分解形成不同实现路径,前提是独立性和相关失效得到充分论证。

图 6 公开主动悬架ASIL示例

六、安全状态不是简单断电,而是受控退化

对部分半主动减振器,失电后落到预定义阻尼可能是可接受的安全状态。对能够主动抬升或压低车轮的全主动系统,立即切断全部能量未必总是安全:作动器可能停在不利位置,左右卸载不同步,也可能在高横向加速度时突然失去姿态支撑。

所以安全概念要区分故障检测、应急运行和最终安全状态。检测到第一故障后,系统可以隔离故障通道,切换到独立通道或受限控制,保持必要的车身高度和轮胎接地能力;随后由整车降低速度、限制激烈操纵并提醒驾驶员,在可接受时间内进入机械被动悬架或其他低风险状态。

英飞凌示例采用双通道思路:主通道故障后进入第二通道的应急运行;如果应急运行超过允许时间或第二故障出现,则关闭主动命令,回到机械被动悬架,并由 ESC 等整车系统管理风险。这一架构仍是示例,量产项目是否需要 fail-operational,要由 HARA 和可接受的安全状态决定。

安全状态必须用可验证参数描述。与其写“悬架进入安全模式”,不如定义允许的四角高度差、作动力或阻尼范围、变化率、最大持续时间、驾驶速度限制、驾驶员提示,以及与制动和稳定控制系统的接口状态。

图 7 主动悬架安全状态与应急运行

七、双通道不等于安全,独立性才是关键

把两套 MCU、两路传感器或两条总线画在框图上,并不能自动获得故障容错。两个通道若共用同一供电、时钟、参考地、连接器、通信交换机、基础软件或状态估计算法,一个共同原因仍可能让它们同时失效或同时输出错误结果。

主动悬架的独立监控至少应覆盖传感、计算、通信、功率驱动和执行器反馈。位置与加速度可以做物理量一致性检查;目标作动力可与电机电流、液压压力或估算实际力比较;通信要检查新鲜度、顺序、超时和端到端保护;功率级要监控过流、欠压、过压、温度和驱动关断路径。

监控器也可能失效。独立监控需要考虑其供电、时钟、输入和软件是否与被监控功能真正解耦。高等级安全需求下,还要用相关失效分析(DFA)检查共享资源、环境应力、开发工具、需求误解和软件共因。

四角系统还有一个独特问题:角模块之间相互影响。单角故障可能通过车身运动改变其余三个角的状态估计;一个错误的全车协调目标也可能同时驱动四个健康执行器做出危险动作。因此,角模块本地保护与整车协调监控应形成两层防线。

图 8 主动悬架双通道安全架构

八、FTTI不是拍脑袋的毫秒数,而是物理风险窗口

主动悬架故障处理时间不能只看控制周期。完整链路包括故障出现、传感或监控发现、诊断确认、故障隔离、备用通道接管、执行器卸载或重新建立力,以及车辆运动收敛。任何一段过长,都可能让车辆在安全机制起效前越过稳定边界。

项目应从车辆危害反推时间预算。可以在整车动力学模型中注入最不利的单角作动力、传感器偏置或冻结命令,观察轮胎法向载荷、横摆率、侧倾角和悬架行程何时超过安全阈值,再为检测、通信、控制切换和执行器响应分配预算。

故障容错时间间隔(FTTI)与故障处理时间不能混用。安全机制的检测、反应和到达安全状态的总时间必须落在项目定义的风险窗口内;对于需要应急运行的系统,还要定义允许保持降级功能多久,以及何时必须进一步降速或停车。具体时间值取决于车辆和场景,不能从别的项目照抄。

最容易被漏掉的是通信和机械时间。域控已经切换命令,不代表角模块立即建立正确作动力;角模块已经关断电流,也不代表液压压力、阀芯位置和车身运动瞬间归零。验证必须测到车辆响应,而不只是软件状态位。

图 9 主动悬架故障处理时间预算

九、功能安全、SOTIF与网络安全要划清边界

主动悬架越来越多地使用摄像头或道路模型做预瞄控制。如果摄像头通信发生位翻转、时间戳错误或软件计算异常,属于 E/E 系统故障导致的功能安全问题。若硬件和软件都按设计工作,但雨雪、逆光或路面纹理使感知性能不足,则更接近 ISO 21448 所讨论的预期功能安全问题。

网络攻击导致高度指令被篡改,则属于网络安全威胁,但最终仍需要与车辆安全分析形成接口。三个领域不能互相替代:ISO 26262 不覆盖没有故障的性能不足,SOTIF 不处理 ISO 26262 已覆盖的故障,网络安全也不能仅靠功能安全监控兜底。

工程上可以共用场景库和车辆指标。例如同一个高速弯道,可以分别注入传感器故障、感知局限和恶意指令,观察车辆效应;但问题来源、接受准则、责任人和证据链需要分别管理。

十、验证要证明“故障后仍安全”,不是只证明诊断报码

主动悬架功能安全验证至少要覆盖五层。模型与 SIL 用于快速扫描失效幅值、方向和时间;HIL 验证控制器、通信、供电和诊断时序;执行器台架验证卡滞、偏置、卸载和热衰减;四立柱或道路台架验证机械回退与四角耦合;整车试验验证极限场景中的稳定性和驾驶员可控性。

故障注入对象不能只盯着传感器断线。还应包括合理范围内的偏置、漂移、冻结、跳变、延迟、数据新旧错乱、总线阻塞、供电欠压、驱动桥故障、执行器效能下降、机械卡滞、过温降额和多个故障的组合。

每个测试用例都要留下闭环证据:注入了什么故障,监控何时检测,系统进入什么模式,备用通道何时接管,作动力和车身运动如何变化,是否在安全时间边界内达到安全状态,以及驾驶员提示和诊断信息是否一致。

通过率不是唯一结论。还要检查未检出故障、误报、抖动切换、重复恢复、跨域指令冲突和故障清除后的重新激活条件。一个会频繁误触发的安全机制,同样可能在真实道路上引入新的风险。

图 10 主动悬架功能安全验证矩阵

十一、评审时最值得追问的十个问题

第一,Item 是否明确区分半主动阻尼与全主动作动?第二,机械弹簧和减振器在失电后能否独立承载并保持基本轮胎接地?第三,危险分析是否覆盖单角、同轴和四角不同步?第四,ASIL 是否来自具体危险事件,而不是来自芯片能力或竞品标签?

第五,安全状态是否写成可测量的高度差、作动力、变化率和持续时间?第六,主通道与安全通道是否真正独立,还是共享了同一供电、时钟和基础软件?第七,通信冻结、延迟和错误新鲜度是否有端到端监控?第八,故障处理时间是否包含执行器和车辆物理响应?

第九,主动悬架退出后,ESC、制动、转向和动力系统分别承担什么责任?第十,验证是否覆盖合理范围内的错误信号和机械卡滞,而不只是开路、短路和报码?

如果这十个问题回答不清,项目即使有完整的 HARA 表格、FMEDA 和测试报告,也可能只是文件齐全,安全链路并没有真正闭合。

十二、工程师总结:先定义危险,再讨论ASIL

主动悬架把舒适、操稳、车身姿态和轮胎载荷连接到同一套高带宽执行系统中。它既可能只是改善体验,也可能在故障时直接影响车辆稳定性。正因如此,功能安全工作不能从“选一颗支持 ASIL D 的 MCU”开始,而应从 Item 边界、失效行为和运行场景开始。

正确的顺序是:定义功能与能量边界,识别故障后的车辆行为,建立危险事件并完成 S/E/C 评估,形成安全目标,再设计监控、应急运行、机械回退、跨域协同和验证证据。ASIL 是这条链路的结果,不是起点。

对全主动悬架而言,最可靠的安全设计往往不是无限堆叠冗余,而是保留可预测的机械基础能力,让电子系统在故障后仍有明确的退路;同时把四角作动、域控、供电、通信和 ESC 看成一个整车安全系统,而不是彼此独立的零件。

图 11 主动悬架功能安全工程结论

   
32   次浏览       4 次
相关文章

中央计算的软件定义汽车架构设计
汽车电子控制系统中的软件开发过程
一文读懂汽车芯片-有线通信芯片
OTA在汽车上有哪些难点痛点?
相关文档

汽车设计-汽车的整体结构及动力系统
自动驾驶汽车软件计算框架
SysML在汽车领域的应用实践
电子电气架构-大陆汽车系统架构平台
相关课程

AutoSAR原理与实践
功能安全管理体系(基于ISO26262)
MBSE(基于模型的系统工程)
基于SOA的汽车电子架构设计与开发

最新活动计划
AI智能体开发实践 9-17厦门/10-22在线
OCSMP 认证培训 9-23[在线]
企业架构方法与实践 9-15[深圳]
UAF架构体系与实践 9-22[北京]
AI系统的测试方法与工具 9-17[北京]
AI时代的软件架构师培养 9-19[上海]
AI时代的需求分析师培养 10-20[北京]
 
 
最新文章
ASPICE中配置管理是个什么东西?
了解软件安全分析与组件鉴定
掌握Autosar ComStack的精髓!
基于整车功能的正向诊断需求开发
搞定Autosar SWC开发秘籍,码住!
汽车OTA更新的系统性威胁评估
最新课程
基于SOA的汽车电子架构设计与开发
Auto SAR原理与实践
AUTOSAR架构与实践(从CP到 AP )
AUTOSAR架构建模方法与工具(EA)
ASPICE4.0核心开发过程指南
MBSE(基于模型的系统工程)
更多...   
成功案例
某知名车企 AUTOSAR应用设计与开发
吉利汽车 MBSE工程体系汽车建模及评估
某整车企业 《功能需求分析与设计》
富奥汽车零部件 建模工具EA
零跑汽车 建模工具EA及服务
北汽福田 建模工具EA
小鹏汽车 建模工具EA
更多...