泊车辅助系统故障 自动驾驶功能安全篇5——系统阶段：TSC（技术安全概念）
本文将结合ISO26262.4中系统阶段：技术安全概念（有删减），分析其内容，并聊聊完整的TSC分析过程。
1、我们为什么做技术安全概念分析？
其目的为：
a) 为实现系统要素和接口的功能、相关性、约束和属性，制定所需的技术安全要求；
b) 为系统要素和接口中将要实施的安全机制，制定技术安全要求；
c) 制定在生产、运行、服务和报废过程中系统及其要素功能安全的相关要求；
d) 验证技术安全要求在系统层面是否符合功能安全要求并与功能安全要求一致；
e) 制定满足安全要求且不与非安全相关要求冲突的系统架构设计和技术安全概念；
f) 分析系统架构设计，以防止故障发生，并导出针对生产和服务必要的安全相关的特殊特性；
g) 验证系统架构设计和技术安全概念是否满足相应ASIL等级的安全要求。
2、技术安全概念需要哪些输入？
—— 功能安全概念（此外，还可以借助HARA及相关项定义文档）;
—— 系统架构设计（外部的，粗略的架构）；
—— 其他涉及安全的相关项对此相关项的要求（如果适用辅助论坛，如：泊车辅助系统对制动系统的要求）。
3、技术安全要求如何做？
技术安全要求应按照功能安全概念、相关项的系统架构设计来定义，需要同时考虑功能安全相关和非功能安全相关的一些要素，非功能安全相关主要考虑外部环境、散热、安装等等，其实在相关项定义中已经定义区分过这些。
技术安全需求（TSR）可以分为两层：
1） 第一层的TSR的写法与功能安全需求（FSR）的逻辑表述基本一致泊车辅助系统故障，需要基于FSR做进一步细化，需要指出：具体的信息及其传输方式（CAN、Eth等），硬件指标要求（单点故障度量SPFM、潜伏故障度量LFM、随机硬件失效度量PMHF）。硬件指标要求与ASIL等级的对照关系如下：
“单点故障度量”目标值的可能推导来源
“潜伏故障度量”目标值的可能推导来源
得出随机硬件失效目标值的可能来源
注：硬件指标的具体计算及分配要求将在硬件阶段进行展开。
2）第二层TSC，对于自动驾驶系统（辅助系统或更高级别）来讲，就需要定义相关的安全机制了，安全机制用于探测故障并防止或减轻出现在系统输出端的违反功能安全要求的失效。
安全机制应该包含：探测随机硬件故障及探测系统性故障的系统自身监控、通信失效的探测和控制的安全机制、外部设备（包括其他的电控单元、电源或者通信设备）、安全机制控制请求的仲裁，以及报警、降级、故障记录。
一般还需要定义安全机制在上下电、运行中等过程的自检。
系统架构设计及其安全分析：
系统架构设计应该基于我们之前的定义的初始架构，并且将我们上面的技术安全要求分配到系统架构上，也就是实现我们的技术安全要求的过程。
系统架构设计完成后就需再次进行安全分析，分析方法比如DFMEA、FTA、DFA（独立性分析）等等。
另外，如果在安全分析或系统架构设计过程中新识别的尚未被安全目标涵盖的危害，应更新到按照危害分析和风险评估（HARA）中。（若未非功能性危害，注释说明即可）
技术安全要求的分配：
系统架构有了、技术安全要求有了，那么技术安全要求应该分配到软件与硬件，明确哪些是软件去做，哪些是硬件去做，便于下一步的设计。
另外，还需定义硬件与软件的交互，即HSI（软硬件接口规范）泊车辅助系统故障，应包含：硬件的运行模式（默认模式、初始化模式等）、硬件设备的配置参数（增益控制、带通频率或时钟分频）、确保要素将独立性的硬件特征、硬件资源的共用和专用（内存映射、寄存器分配、计时器、终端、I/O端口）、硬件设备的访问机制（串、并、从、主/从）、硬件的诊断特性（过流、短路或过温的探测）。