04 – 汽车功能安全(ISO 26262)系列: 系统阶段开发 – 技术安全需求(TSR)及安全机制

本篇属于汽车功能安全专题系列第04篇内容，我们主要聊聊，到底什么是技术安全需求(TSR)和安全机制(Safety Mechanism)。

在上一篇:

”03 – 汽车功能安全(ISO 26262)系列: 概念阶段开发 – 功能安全需求及方案(FSR&FSC)” 

我们在概念开发阶段，通过组件层别的安全分析(FTA, FMEA)对功能安全开发最初的安全需求，即安全目标(SG)，进行细化，得到了组件级别的功能安全需求(FSR)和方案(FSC)。

但FSR本质上还是属于功能层面的逻辑安全需求，属于”需要做什么”的层次，无法具体实施，所以需要将FSR进一步细化为技术层面的安全需求(TSR)，即”怎么做”，为后续的软件和硬件的安全开发奠定技术需求基础。

根据ISO 26262，功能安全系统阶段开发内容可以分为两大部分:

• 技术安全需求及方案开发及验证

• 系统集成测试及安全确认(Validation)

它们在开发过程中并不连续，分别隶属于系统开发V模型的左边和右边，中间穿插了硬件和软件开发。系统阶段技术安全需求(TSR)和方案(TSC)开发和概念阶段功能安全需求(FSR)和方案(FSC)一脉相承，和概念开发开发紧密衔接。只有硬件和软件开发完成，才能进行系统层面集成测试和需求确认。

系统集成这部分我们留在软件和硬件开发之后再聊。针对第一个大的部分，即技术安全需求(TSR)和方案(TSC)，我们主要聊以下内容:

• 什么是技术安全需求TSR

• 安全机制的本质

• 怎么从FSR到TSR

• 什么是技术安全方案TSC

• 系统安全架构设计

• 安全分析

• 技术安全需求分配至系统架构
  

鉴于内容较多，今天我们先聊前三部分内容。

总体而言，技术安全需求(TSR: Technical Safety Requirement)是为满足安全目标SG或功能安全需求(FSR)，由功能安全需求(FSR)在技术层面派生出的可实施的安全需求。

那到底什么是由FSR派生出的技术安全需求呢？

根据ISO 26262的定义，技术安全要求(TSR)应该明确功能安全需求在各自层级的技术实现; 考虑相关项定义和系统架构设计，解决潜在故障的检测、故障避免、安全完整性(即满足ASIL等级)以及产品生产和服务方面的必要安全问题。

什么意思呢？直接上个我自己总结的公式:

技术安全需求(TSR) = 由FSR技术化的安全需求 + 安全机制 + Stakeholder需求

• 由FSR技术化的安全需求

将FSR进一步技术化，得到可以实施的技术安全需求，是TSR的重要来源，但它只是TSR其中一个组成部分。

所谓FSR技术化的安全需求就是，基于系统架构中组件分配得到的FSR，根据该组件内部以及对外的依赖关系和限制条件，将FSR定义的逻辑功能需求进行技术性转化和体现。

这部分技术需求属于相对基础的TSR，不涉及深层次的探测，显示，控制或减轻系统出现故障的安全措施，所以并不能保证系统功能安全。它的主要的目的是为后续相关安全机制的开发或者需求的提出奠定技术基础。

例如，由FSR技术化的安全需求包括，定义逻辑功能需求中所涉及的软件组件，硬件组件(传感器，控制单元，执行单元)，组件接口技术信息(如信号名称，来源等)，传输方式(CAN总线等)，计算周期，软件组件不同平台复用配置需要的标定数据，硬件组件指标要求等。

• 安全机制

安全机制(Safety Mechanism)目的在于探测，显示和控制故障，属于功能安全事后补救措施，是TSR非常重要的组成部分，是实现功能安全，防止安全目标SG或者功能安全需求FSR违反的重要技术实现手段之一。

安全机制应该包含：

检测系统性及随机硬件故障的措施。例如，针对系统I/O，总线信号范围检查，冗余校验，有效性检测，逻辑计算单元数据流及程序流监控，控制器硬件底层软件监控等。

显示故障。例如，对驾驶员进行声音，不同类型及颜色的指示灯，提示文字等预警，增加驾驶员对车辆的可控性。

控制故障的措施。例如，Fail to safe: 将系统在指定的故障容错时间间隔(FTTI)导入安全状态，包括降级，故障仲裁，故障记录等。如果不能，还需要定义紧急运行时间间隔及运行状态。或者Fail to operational，通过并行冗余系统，当一个系统失效后，进入另外一个并行系统继续提供全部或部分功能。少。

• Stakeholder需求

Stakerholder需求主要包括车辆使用，法律法规，生产和服务方面相关的安全需求。一般都是以具体技术细节直接进行呈现，所以会直接并入TSR之中。

例如，车辆发生碰撞后，相关项应该采取的哪些应对措施，可能是转矩输出非使能，高压系统断电等。

此外，针对TSR，还需要注意以下几点:

接下我们聊聊困惑很多朋友的一个问题: 安全机制到底是什么，它和TSR到底有什么区别?

在ISO 26262-4:2018中，TSR和安全机制这两部分内容独立成章节，并没有合在一起进行阐述，这给很多朋友造成一种误解，认为安全机制和TSR好像是不一样的存在，它们之类的区别也不够清楚。下面我从三个方面来阐述一下安全机制的本质: 

1. 安全机制属于更深层次的TSR

安全机制是为防止SG或FSR的违反，基于由FSR技术化的安全需求，提出的更深层次的事后补救技术安全措施，它包括:

由FSR技术化得到的TSR的安全机制，主要是防止系统性故障，或硬件单点故障潜伏提出的技术安全需求。

以及安全机制的安全机制。例如针某TSR提出了已经有了安全机制A，但由于该TSR的ASIL等级较高(C或D)，安全机制A本身也可能失效，此时如果原有功能正常，系统不会违反安全目标SG，但安全机制A的失效就会潜伏，变成双点故障，所以需要对安全机制A的功能安全进行监控，提出针对安全机制A的相应的技术安全需求，防止安全机制A的故障潜伏。

一般来讲，考虑到系统实现的成本和复杂度，安全机制不超过两层。根据ISO 26262，三点及以上故障就可以认为安全故障，否则就会出现无穷的安全机制嵌套。

2. 安全机制是实现相应ASIL等级的关键之一

除ISO 26262对不同开发过程的约束(包括方法，验证等)外，在系统，软件和硬件开发阶段，不同ASIL等级直接决定了应该采取哪些安全措施，以及安全措施的类型(或高级层度)。

越高的ASIL等级对应的安全措施，在数量和质量的要求越高。例如，对于ASILB的系统，可能具有单独时间Base的Watchdog可能就够了，但是对ASILD系统而言，可能需要上程序流逻辑监控才能满足。

当然不同的安全机制在实施难度和成本上都有所不同，这部分内容我会在后续的专题里一步步讲解。

3. 安全机制多和系统安全架构设计相关，一定程度上决定了系统安全架构

安全机制是保证系统功能安全的非常重要的技术手段，而这些技术手段，例如，硬件冗余，输入输出有效性检验，安全状态导入，或我们常见的控制器3层安全监控架构等等，这些都直接决定了我们系统的安全架构，会在架构设计中进行考虑，直接融入架构设计之中。这个也是为什么在功能安全在系统阶段开发过程中，花很大的篇幅来讲安全机制和架构设计的重要原因之一。

为了方便理解安全机制，我们一起来看个关于加速踏板开度采集的例子:

其中，左边属于由FSR技术化的安全需求，主要是明确加速踏板技术信息，包括采用什么样传感器，输出信号有哪些，类型，采样周期等。

在实际系统开发过程中，为实现相应的ASIL等级，控制系统一般进行分层设计，功能安全拥有独立的软件层和硬件层，开发过程相对独立，甚至独立的开发团队。

为实现后续安全监控，需要将安全相关的应用层功能在监控层进行多样化设计复现，所以这部分TSR和我们正常的系统应用层功能开发需求有点类似，但不是完全复制，而是多样化，差异化的设计实现，所以这些信息或者需求会和应用层功能实现存在一定关联。

右边是安全机制，是更深层次技术安全需求，这些都是保证系统功能安全的关键技术手段。

上面我们聊到TSR的具体组成部分，包括由FSR技术化的TSR，安全机制和Stakeholder需求。

前两部分TSR的导出，和概念阶段聊到的SG到FSR类似，都是通过安全分析(即FTA，FMEA分析方法)完成。

以FTA分析为例，主要是将违反的FSR作为顶层分析事件，进行原因分析，安全分析的具体细节我在这里就不重复了，不熟悉的朋友移步功能安全专题03篇内容。

实际操作过程中，对于比较简单的FSR，即涉及的组件功能的比较简单，完全可以依据经验直接导出，对于相对比较复杂的FSR则需要进行完整的安全分析。

对于Stakeholder需求，一般需要根据Item Definition中定义的法律法规及之前项目经验进一步细化，一般情况下，该部分需求可以在不同项目中可以复用。

TSR和安全机制我们就聊完了，网络上很多关于它们的介绍都太表面，照抄标准，希望这篇能够给朋友们理解TSR和安全机制带来帮助，下期我们继续看功能安全系统阶段开发其他内容。

奈何现有公众号没有留言功能，感兴趣的朋友可以直接公众号私信我或者通过公众号下方菜单栏”联系我”，添加好友，免费加入”读者交流社区“，共同探讨。

END

【点赞】和【在看】= 原创的动力

                                 多谢【点赞】和【在看】

原文始发于微信公众号（AUTO世代）：04 – 汽车功能安全(ISO 26262)系列: 系统阶段开发 – 技术安全需求(TSR)及安全机制