ISO 26262 Technical-Safety-Concept（一）
利用周末的时间看了小米十年的公开演讲，雷布斯用将近三个小时的时间回顾了小米热血的十年，以及对下一个十年的展望。小米的十年同时也是雷布斯的十年。不禁感慨，人生有几个十年？作为一个普通人，我们的第一个十年又在哪里呢？话不多说，本期继续跟大家聊一聊ISO 26262 TSC相关的话题，一起来学习吧！
01
概述
技术安全概念（TSC）是展开具体硬件和软件安全要求的基础，开发团队按照系统需求和软硬件的技术安全要求来开发我们的产品。当我们按照ISO 26262完成了系统概念阶段的设计之后，接下来就需要把这些功能块分配到具体的物理架构中来。也就是说，技术安全概念阶段会把概念阶段的要求进一步细化到产品的软硬件开发中来，它规定了系统级的产品开发要求，包括：
技术安全概念 － Technical Safety Concept；
系统架构设计 － System Architecture Design；
相关项的集成和测试 － Item Integration and Testing；
安全验证 － Safety Validatoin；
而在前面的几期中，我们已经把功能安全概念阶段（FSC）相关的内容都梳理完了。在技术安全要求阶段，我们也会去验证一些车辆级别的FSC（这一块具体可以参考下ISO 26262 Part4 第8章）下图展示了ISO 26262的V模型，我们的开发也从概念阶段转到了具体的系统设计阶段。
02
技术安全概念
1． 主要任务：
明确相关功能的技术安全要求（TSRs）；
相关项要素和接口安全机制的技术安全要求（TSRs for Safety Mechanisms）；
详细的FSRs；
利用故障树分析（FTA）或者故障模式和影响分析（FMEA）对系统架构进行分析，得出基本的故障时间，并且提供系统安全机制来阻止故障；
根据各自的ASIL 等级，验证系统架构和技术安全概念是否满足安全要求；每个安全目标都要满足各自的诊断覆盖率（请看下面的图片，详细内容参见ISO 26262 Part5 Annex D）
2． 本章节的输入：
功能安全概念文档；
系统架构设计（它可以与SPICE的SYS3．3兼容，也可以来自提供团队）；
其他安全相关的相关项的要求（如果适用的话）→如果其他的相关项对我们所要设计的系统有要求，这里也需要提供。
更多的支持信息（HARA，相关项定义）；
比如：有些SbW要求可以应用于制动系统，来约束转向请求方法，见下面的图片。
-
焦点事件
-
标准
-
标准
