本篇属于汽车功能安全专题系列第05篇内容，主要聊功能安全系统开发阶段，技术安全方案TSC和安全分析相关的内容。
开始阅读之前强烈建议参考之前系列文章:
02 – 汽车功能安全系列之概念阶段开发 – Item Definition & HARA
03 – 汽车功能安全(ISO 26262)系列: 概念阶段开发 – 功能安全需求及方案(FSR&FSC)
04 – 汽车功能安全(ISO 26262)系列: 系统阶段开发 – 技术安全需求(TSR)及安全机制
功能安全第四部分系统开发阶段，主要包括以下内容:
-
什么是技术安全需求TSR
-
安全机制的本质
-
怎么从FSR到TSR
-
什么是技术安全方案TSC
-
系统安全架构设计
-
安全分析
-
技术安全需求分配至系统架构
在上一篇:
”04 – 汽车功能安全(ISO 26262)系列: 系统阶段开发 – 技术安全需求(TSR)及安全机制”
我们详细地介绍前三部分内容，即技术安全需求(TSR)，安全机制(Safety Mechanism)的本质，从FSR到TSR导出。
今天我们先接着关于技术安全方案TSC以及安全分析相关的内容，系统安全架构内容较多，我们下一篇单独聊。
01
什么是TSC
聊完技术安全需求TSR(04篇)，其实技术安全方案(TSC)相对比较容易理解，TSC和03篇概念阶段讲到的FSC类似，属于系统阶段围绕TSR开发的工作内容汇总，形成的系统化工作输出结果。
一般来讲，一个完整的TSC应该包含以下主要内容:
除此TSR之外，系统安全架构也是TSC不可或缺的重要内容，需要对系统架构功能安全部分内容进行开发，得到系统安全架构，作为系统阶段TSC的重要内容，这个我们下一篇聊。
那TSC结构应该如何组织，和FSC有什么区别？采用什么工具进行书写呢?
FSC属于概念开发阶段主要工作输出产物，除技术文档基本的格式外(包括作者，版本记录，输入，适用范围，缩写等)，主要包含三大部分内容:
-
相关项定义内容进行描述。
-
安全目标SG和技术安全需求FSR: 一般是按照安全目标SG进行结构组织，分别罗列每个安全目标SG下，对应的功能安全需求FSR。
-
安全状态: 一般针对每个或者多个安全目标SG设定系统安全运行状态。
对于TSC:
TSC主要是描述由FSR导出的技术安全需求和安全机制。
由于FSR数目众多，所以TSC不太可能直接按照FSR进行罗列对应的TSR，并且考虑到后续需要将TSR分配至系统架构，所以TSC更多的是按照系统组件或功能集合进行结构组织，阐述每个组件或功能集合下，对应的TSR，并区分该需求由软件，硬件或二者共同实现。
关于书写工具，TSC和FSC类似，可以采用Word等基本文本工具，或采用相对比较专业的需求管理软件，例如Doors等。对于TSC最好可以结合架构设计工具，例如Enterprise Architect等，将需求和架构关联起来。
此外，在TSC中需要将TSR分配至系统架构，还需要保证TSR和FSR之间的关联，这样就可以形成了SG，FSR以及TSR之间完整的Traceability。还可以进一步将系统级别测试用例和TSR关联，这样就形成了不同类型需求之间完整的可追溯性和可验证性，这个在功能安全评审过程中非常重要。
02
安全分析
安全分析是功能安全最重要的内容之一，它伴随功能安全整个开发过程，是所有安全开发工作的基础，但在每个开发阶段侧重点有所不同。
在概念阶段，安全分析侧重整车功能分析，首先采用系统或者整车级别安全分析方法HAZOP导出SG，然后利用FMEA或FTA安全分析方法， 由SG导出FSR。
在系统阶段，安全分析，除了由FSR导出TSR以外，侧重点在于对系统架构的分析，主要有以下两个目的:
-
对系统安全架构进行分析，提供系统设计适合性的证据，确保系统架构可以实现安全相关的需求和属性，以及对应ASIL等级。 -
对系统进行复查，识别以系统架构没有覆盖的故障原因和风险。对于新识别出危害，必须重新按照HARA过程进行分析和更新，并对FSR和TSR和架构进行完善。
对于安全分析方法而言，不管在哪个开发阶段(包括概念，系统，软件，硬件)，无非就以下两种:
-
归纳分析法(Inductive analysis): FMEA(Failure Mode and Effects Analysis，即失效模式与影响分析)，定性分析。
-
演绎分析法(Deductive analysis): FTA(Fault Tree Analysis, 即故障树分析)，可定性和定量分析。定量分析多用于硬件指标计算。
概念阶段HAZOP也属于归纳分析法，其本质和FMEA一致，可以认为是整车级别简化的FMEA。
FMEA和FTA的本质区别具体见功能安全系列03篇(点我)内容，在此不再重复了。
最后，谈谈大家对安全分析的一个误解，很多朋友，谈到安全分析，第一反应是用什么安全分析工具？
其实安全分析方法和过程都很明确，简单的说:
-
FMEA就是从系统实现功能去分析它们可能存在的潜在失效情况和故障。 -
FTA正好反过来，如果出现这种失效或者故障，可能是由系统哪些部件或功能导致。
很多朋友过于强化安全分析工具的作用，寄希望于通过特定安全分析工具来实现不同阶段的安全分析，认为有了分析工具就搞定了一切。
但这些分析工具只是支持手段，把我们安全分析的思路和过程记录下来而已，很多大企业目前还是采用Excel照样做安全分析。重点在于我们对系统的了解和认知程度，这些直接决定了安全分析的结果的可靠性和全面性，这个也是安全分析的难点。
当然，世面上也有些把车辆失效和故障情况集成到安全分析工具中，实现快速安全分析。但这样的分析工具很难和我们具体研究对象一致，可靠性也难以评估，也没有必要。安全分析是功能安全工作的基础，基础没有亲自去完成，做到充分了解，那后面工作很难开展。
所以，还是多花点时间去认识研究对象，安全分析自然水到渠成，这个才是核心。
03
TSR分配至系统架构
那具体如果确定一个组件的ASIL等级呢？
系统架构中的组件的ASIL等级源于分配到组件的TSR的ASIL等级，具体来讲，应该满足以下约束:
1
2
如果一个组件由多个子部件构成，且分配给子部件的TSR对应的ASIL等级(包括QM)不同，则每个子部件应该按照以下两个原则之一进行开发:
-
所有子部件分别按照所有TSR中最高的ASIL等级。
-
如果各子部件满足要素共存或免于干扰原则，即FFI(Freedom From Interference)，则各子部件按各自ASIL等级开发。
这里需要注意免于干扰(FFI) 和ASIL等级分解独立性原则(Independence)区别:
FFI: 要避免在两个或者更多要素之间由于级联失效而导致的违反功能安全要求。
ASIL等级分解独立性: 除保证无级联失效外，还需要保证无共因失效问题。所以独立性要求更为广泛，需要通过相关失效分析(DFA)证明。
那为什么FFI只要求避免级联失效，而ASIL分解独立性要求，除避免级联失效外，还要求避免共因失效呢？
二者需要解决的问题不同:
FFI旨在解决不同ASIL等级(包括QM)组件共存的问题，需要对不同ASIL等级组件进行有效隔离，防止低ASIL等级组件故障蔓延或者影响到其他高ASIL等级组件，即防止串联失效，这属于级联关系的失效。
共因失效，即共同外部因素错误导致的组件失效，可以简单理解为并联失效。不管组件之间是否进行了隔离，只要有共同的外部错误输入，涉及的组件一定会出现故障，所以共因失效和FFI无关。
ASIL分解旨在，在保证原有安全性的情况下，将高ASIL等级需求分解成两个独立的低ASIL等级需求，一般这两个低ASIL等级需求会分配至两个不同组件，由此降低组件开发难度。
那怎么才能用低ASIL等级实现原有安全需求呢？
独立性，说白了是强调不一起发生故障，两个组件只有即不发生串联失效，也不发生并联失效的情况下，才可以保证不一起出现故障。
FFI是后续软件功能安全开发重要的内容，和控制器基础软件相关，ISO 26262中定义了以下几种要素干扰情况:
-
执行和时序(Timing &Execution)干扰 -
内存(Memory)干扰 -
信息交换(Exchange of information)干扰
这部分内容相对比较复杂，我们今天先让朋友们了解这些概念和产生的背景，具体的干扰情况及对应的安全机制，我们之后单独细聊。
写在最后:
，希望这篇能够给朋友们理解TSC和安全分析带来帮助，下期我们继续看功能安全系统开发阶段之系统安全架构设计内容。
。
END
【点赞】和【在看】= 原创的动力
多谢【点赞】和【在看】
往期推荐
原文始发于微信公众号（AUTO世代）：05 – 汽车功能安全(ISO 26262)系列: 系统阶段开发 – 技术安全方案TSC及安全分析
