ISO 26262中文网站 > 使用教程 > ISO 26262怎么进行ASIL分解 ISO 26262 ASIL分解后安全要求怎么分配
教程中心分类
ISO 26262怎么进行ASIL分解 ISO 26262 ASIL分解后安全要求怎么分配
发布时间:2026/08/17 15:18:07

  在汽车功能安全开发中,ASIL等级越高,对开发流程、验证深度和独立性的要求也越高。ISO 26262怎么进行ASIL分解,ISO 26262 ASIL分解后安全要求怎么分配,核心是通过架构冗余把高等级安全要求分配给相互独立的实现路径,同时保证原安全目标要求的安全完整性没有降低。ISO 26262-9专门规定了与ASIL相关的要求分解、元素共存和相关失效分析要求。

  一、ISO 26262怎么进行ASIL分解

 

  ASIL分解针对的是安全要求及其实现方案,不能简单理解为把一个ASIL D功能改成两个低等级功能。分解后的两条路径需要共同满足原始安全要求,并具备足够的独立性。

 

  1、先确认安全要求是否适合分解

 

  ①从危害分析与风险评估结果向下追踪,确认当前要求继承的ASIL等级和对应安全目标。

 

  ②检查该安全要求能否通过两条独立实现路径共同满足,例如【主功能路径】与【独立监控路径】。

 

  ③确认两条路径不会依赖同一个容易形成单点故障的关键资源。

 

  ④如果无法建立有效冗余或独立性不足,继续按照原ASIL等级开发,不要为了降低实现等级强行分解。

 

  ASIL分解并不会修改原安全目标的ASIL。例如原始安全目标为ASIL D,分解后仍然需要证明整体方案能够满足ASIL D要求。

 

  2、按照允许组合确定分解等级

 

  常见做法是把较高ASIL要求拆成两个较低等级、但相互冗余的要求。工程中经常使用的组合包括【ASIL C=ASIL B(C)+ASIL A(C)】,以及【ASIL D=ASIL B(D)+ASIL B(D)】或【ASIL D=ASIL C(D)+ASIL A(D)】。其中括号内的等级用于保留原始要求的ASIL来源。

 

  ①先确定待分解要求当前属于【ASIL B】【ASIL C】还是【ASIL D】。

 

  ②依据项目架构选择符合标准原则的分解组合。

 

  ③为分解后的两条安全要求分别建立唯一编号。

 

  ④在需求管理工具中保留它们与原始安全要求、安全目标之间的追踪关系。

 

  ⑤后续评审时同时检查两条要求,不能把其中一条单独看成完整的安全目标实现。

 

  3、检查两条路径是否真正独立

 

  独立性是ASIL分解能否成立的重要前提。ISO 26262对ASIL分解明确包含独立性要求,同时Part 9还要求进行相关失效分析。

 

  ①检查两条路径是否使用同一传感器、供电、时钟、通信链路或计算资源。

 

  ②检查一个软件故障是否可能同时破坏两条安全路径。

 

  ③分析【共因失效】和【级联失效】,确认单一故障不会让两个分解要求同时失效。

 

  ④发现共享资源无法避免时,增加隔离、独立监控或其他安全机制,并重新评估独立性。

 

  二、ISO 26262 ASIL分解后安全要求怎么分配

 

  分解完成以后,需要把每条要求分配到明确的系统、硬件或软件元素。分配时最重要的是保持功能职责清楚,并避免两条路径最终落到同一个失效源上。

 

  1、分别建立分解后的安全要求

 

  以ASIL D要求分解为两个ASIL B(D)要求为例,两条要求不能写成完全相同的一句话,而要体现不同实现职责。

 

  ①第一条要求定义【主功能安全行为】,明确正常路径需要达到的安全状态或控制效果。

 

  ②第二条要求定义【独立检测或控制行为】,负责发现主路径异常并采取安全措施。

 

  ③分别给两条要求设置【ASIL B(D)】属性。

 

  ④保留两条要求共同追踪到原ASIL D要求的关系。

 

  这种结构能让后续硬件设计、软件设计和测试人员清楚知道每条要求由谁实现、如何验证。

  2、把要求分配给不同架构元素

 

  ①将第一条要求分配给负责正常功能实现的控制元素。

 

  ②将第二条要求分配给独立监控器、冗余控制器或其他安全元素。

 

  ③检查两个元素之间是否存在不必要的共享变量、共享内存或共同故障源。

 

  ④如果不同ASIL软件运行在同一处理器上,应进一步确认时间、空间和数据方面的隔离措施。

 

  ⑤完成分配后更新系统架构和安全需求追踪关系。

 

  AUTOSAR的功能安全资料同样强调,不同安全等级的软件组件共存时需要保证相互之间的干扰受到控制。

 

  3、同步建立验证要求

 

  ASIL降低的是单条分解要求对应的开发等级,并不意味着可以减少整体安全论证。

 

  ①针对每条分解要求分别建立测试或验证活动。

 

  ②增加【独立性验证】,检查两条路径是否可能同时受到一个故障影响。

 

  ③通过故障注入验证主路径失效时,另一条路径能否完成预期安全动作。

 

  ④检查测试结果能否分别追踪到两条分解要求和原始安全要求。

 

  三、ASIL分解完成后还要重点检查什么

 

  分解方案在设计阶段成立,不代表实现完成后仍然保持独立。硬件复用、软件整合和接口调整都可能重新引入相关失效。

 

  1、重新进行相关失效分析

 

  ①根据最终系统架构更新【相关失效分析】。

 

  ②重点检查共享供电、时钟、存储器、总线和公共软件服务。

 

  ③发现新的共因或级联失效后,补充安全机制或调整要求分配。

 

  ④确认修改没有破坏原先的ASIL分解假设。

 

  2、保持需求到验证的完整追踪

 

  ①检查原安全要求与两条分解要求之间的追踪关系。

 

  ②继续向下确认系统、硬件和软件实现都能够对应到具体要求。

 

  ③向验证端检查测试用例和测试结果是否覆盖两个分支。

 

  ④设计变更后重新确认分解依据和独立性结论。

  总结

 

  ASIL分解的价值在于利用合理的冗余架构控制高等级功能安全开发复杂度,同时保持原安全目标要求的安全完整性。ISO 26262怎么进行ASIL分解,ISO 26262 ASIL分解后安全要求怎么分配,判断方案是否合理时不能只关注分解后的等级,还应关注两条实现路径能否长期保持独立,以及安全论证和需求追踪是否完整。希望本文对大家理解ASIL分解和安全要求分配有所帮助,如需进一步了解ISO 26262 ASIL分解与分解后安全要求分配,欢迎联系咨询。

读者也访问过这里:
135 2431 0251