汽车功能安全基础（七）——Part4系统开发阶段

汽车功能安全基础（六）——Part4系统开发阶段_fta 开发-优快云博客 文章浏览阅读1.3k次，点赞30次，收藏14次。技术安全需求（TechnicalSafetyRequirement；TSR）是为了满足安全目标（SG）和功能安全需求（FSR），由功能安全需求（FSR）在技术层级衍生出的可实施的安全需求。TSR = 由FSR技术化的安全需求 + 安全机制 + 生产运行服务报废相关要求​​​​​​1.2 由FSR技术化的安全需求由FSR技术化的技术需求包括：定义逻辑功能需求时所涉及的软件组件，硬件组件（传感器，控制单元，执行单元）；组件接口技术信息（如：信号名称，来源等）；_fta 开发https://blog.youkuaiyun.com/qq_54112829/article/details/143557108?spm=1001.2014.3001.5502

 在上一篇详细地介绍了系统开发阶段的TSR和安全机制，今天主要介绍一下TSC、安全分析相关的内容。

目录

1、什么是TSC

1.1 定义

2、安全分析

2.1 定义

2.2 不同开发阶段的安全分析

2.3 安全分析方法具体介绍

2.4 安全分析的工具

3、TSR如何分配至系统架构

3.1 目的

3.2 级联失效与共因失效

3.3 不同类型相关失效的关系

3.4 确定组件的ASIL等级

3.5 FFI和ASIL等级分解独立性原则区别

---

1、什么是TSC

1.1 定义

理解为系统阶段围绕TSR开发的工作内容汇总。主要包括：技术安全需求TSR、安全机制、系统安全架构、TSR分配至系统架构。

注：TSC主要是描述由FSR导出的技术安全需求和安全机制。

2、安全分析

2.1 定义

安全分析是功能安全最重要的内容之一，贯穿整个开发过程，是所有安全开发内容的基础，但是针对不同的阶段，侧重点有所不同。

2.2 不同开发阶段的安全分析

概念阶段：注重整车功能的分析，首先采用HAZOP方法（注：属于归纳分析法，可认为是整车级别简化版的FMEA）导出SG。（参考如下文章），然后利用FMEA或FTA安全分析方法，从SG得到FSR。

汽车功能安全基础（四）——Part3概念阶段开发_功能安全part3-优快云博客文章浏览阅读1.3k次，点赞41次，收藏24次。通过对相关相所实现的功能进行危害分析和风险评估（HARA），导出功能安全开发最初安全目标（Safety Goal）以及功能安全需求（FSR）。_功能安全part3https://blog.youkuaiyun.com/qq_54112829/article/details/143423586?spm=1001.2014.3001.5502

注：对于安全分析方法来说，不论在概念，系统，软件，硬件哪个阶段，无非就是两种方式：

• 归纳分析法：FMEA（Failure Mode and Effects Analysis, 即失效模式与影响分析）
• 演绎分析法：FTA（Fault Tree Analysis, 即故障树分析）

2.3 安全分析方法具体介绍

FMEA：从系统实现功能去分析它们可能存在的潜在失效情况和故障。

FTA：如果出现这种失效或者故障，可能是由系统哪些部件或功能导致。

具体内容见功能安全基础（五），点击如下链接，在此不再重复介绍。

汽车功能安全基础（五）——Part3概念开发阶段_ftti 汽车-优快云博客文章浏览阅读1.4k次，点赞32次，收藏22次。功能安全目标(SG)属于基于车辆或系统级别的安全需求，过于抽象，我们需要将其进行细化，得到为满足安全目标，基于组件级别的相对比较具体的，但依旧还是基于功能层面的逻辑功能需求，这个就是FSR。故障避免，是指减少故障发生的措施；故障探测，是指对故障或其导致的功能异常表现的控制；故障容错，是指是指在属于特定故障集的故障发生后，至少在有限时间内提供特定功能的能力；故障情况下的功能降级（例如，跛行回家）；如果适用，从一个安全状态过渡到另一个安全状态；_ftti 汽车https://blog.youkuaiyun.com/qq_54112829/article/details/143479666?spm=1001.2014.3001.5502

2.4 安全分析的工具

建议把安全分析的思路和过程记录下来，采用Excel即可。此过程重点在于我们对系统的了解和认知程度，将会直接决定了安全分析的结果的可靠性和全面性。

3、TSR如何分配至系统架构

3.1 目的

根据ISO 26262第4部分的要求，TSR需要分配至系统架构，作为TSC的重要组成部分。将TSR以及对应的ASIL等级落实到架构中具体软件或硬件的组件中，如此就可以明确系统中不同组件在后续阶段开发过程中所需安全需求以及对应的ASIL等级，为下一阶段的软硬件开发提供输入。

3.2 级联失效与共因失效

共因失效和级联失效，合称关联失效。

级联失效：是指同一个相关项中，一个要素的失效导致引起另外一个或多个要素失效。

例：快递公司每天要送200件快递，由两个快递员配送，每人每天配送100件。由于快递员A得了重感冒，传染给快递员B，从而导致快递员B也感冒（failure），导致快递无法配送。

共因失效：一个相关项中，由一个单一特定事件或者根本原因（共因源）引起的两个或者多个要素的失效。

例：快递公司每天要送200件快递，两个快递员配送，每人每天配送100件。由于天气骤冷（共因源），导致两个快递员都感冒发烧（failure），导致快递无法配送。

3.3 不同类型相关失效的关系

下图描述了相关失效、免于干扰和技术独立性之间的关系。免于干扰是用于证明分配了不同ASIL等级的，或者无ASIL等级和有ASIL等级的要素可以共存。免于干扰和不存在共因失效，是用于证明在进行ASIL等级分解时的独立性。

3.4 确定组件的ASIL等级

系统架构中组件的ASIL等级来自于分配到组件TSR的ASIL等级，应满足：

• 组件应集成分配给它的所有TSR中最高的ASIL等级，作为系统组件开发的ASIL等级。
• 如果一个组件由多个子部件构成，且分配给子部件的TSR对应的ASIL等级（包括QM），那么所有子部件应按照如下原则进行开发：

1、所有子部件按照所有TSR中最高的ASIL等级进行开发。

2、如果各个子部件满足要素共存或免于干扰原则，即FFI（Freedom From Interference），则各个子部件按照各自的ASIL等级开发。

3.5 FFI和ASIL等级分解独立性原则区别

FFI：FFI旨在解决不同ASIL等级(包括QM)组件共存的问题，需要对不同ASIL等级组件进行有效隔离，防止低ASIL等级组件故障蔓延或者影响到其他高ASIL等级组件，即防止串联失效，这属于级联关系的失效。

ASIL等级分解独立性：除保证无级联失效外，还需要保证无共因失效问题，所以独立性要求更广泛，需要通过相关失效分析（DFA）证明。在保证原有安全性的情况下，将高ASIL等级需求分解成两个独立的低ASIL等级需求，一般这两个低ASIL等级需求会分配至两个不同组件，由此降低组件开发难度。

注：关于ASIL等级分解，后续单独介绍，这里不再详细展开。