ISO 26262基于V模型，汽车功能安全性的开发始于概念阶段，主要包括以下内容：
项目定义，即定义研究对象。
危害分析和风险评估(HARA)，即得出安全目标和ASIL水平。
功能安全方案开发(FSC)，即在系统概念阶段形成工作方案的输出。
在上篇文章《02-汽车功能安全系列概念阶段开发-项目定义HARA》(我是链接)中，我们谈到了前两部分，定义了功能安全研究的对象，即相关项目，通过HARA过程对相关项目的功能进行系统级安全分析，导出危害事件并量化其风险(ASIL)，最终得到功能安全目标(SG)及其目标。
今天主要讲功能安全概念阶段的第三部分(强烈建议先看前面的文章)，包括：
什么是功能安全要求(FSR)
什么是功能安全计划(FSC)
如何从安全目标中获得功能安全要求(FSR)
FSR被分配到系统架构
01
什么是FSR？
功能安全要求(FSR)是我们在概念阶段经常听到的概念之一，那么什么是FSR呢？
功能安全目标(SG)属于基于车辆或系统层面的安全要求，过于抽象。我们需要对其进行提炼，得到一个相对具体的基于组件级的逻辑功能需求，但仍然基于功能级，这就是FSR。
你可能会好奇，为什么要大费周章，直接细化到技术层面，信号水平不好？
是的，不好！一方面，研究分析工作需要循序渐进，不能一口吃个大胖子。对于简单的或者非常熟悉的研究对象，有了大牛的加持，你或许可以直接从安全目标中推导出技术安全需求，但是对于大多数系统或者大多数工程师来说，这是非常难做到的，很容易出错或者遗漏。另一方面，没有中间工作产品，功能安全审查就过不了关。
那么应该从哪些方面定义组件级的功能安全需求或者功能安全需求应该解决哪些问题呢？根据FSR，ISO 26262-3-2018的功能安全要求应针对以下几个方面，并提出相应的功能级解决方案：
防止事故
故障检测、控制故障或异常功能
过渡到安全状态
容错机制
发生错误时的功能退化以及与驾驶员预警的相互配合
将风险暴露时间减少到可接受的持续时间所需的驾驶员警告。
驾驶员预警，增加驾驶员对车辆的可控性。
车辆级时间相关要求，即容错间隔、故障处理间隔和仲裁逻辑，从不同功能同时产生的多种请求中选择最合适的控制请求。
怎么理解呢？一般来说，FSR无非是从以下两个角度定义安全需求：
提前注意事项：从设计的角度来说，为了尽可能避免系统中的软件和硬件出现故障，系统中的组件应该实现或具备什么功能。
事后补救：如果系统仍有故障，及时检测、显示和控制故障。尽早提醒驾驶员故障，让驾驶员有效干预，或者控制车辆系统进入安全状态，从而预防或减轻伤害。
此外，对于FSR，应注意以下几点：
一个
FSR的本质是需求，一般是甲方(OEM)对供应商提出的安全要求。仅考虑系统应如何正常工作才能满足安全目标和ASIL水平，不涉及具体的技术实现方法。
2
每个SG至少应导出一个FSR。
三
FSR应该继承相应安全目标的ASIL水平。如果ASIL存在等级分解，就必须遵循ISO 26262-9:2018独立的要求。(注意独立性和抗干扰性(FFI)之间的区别)
四
如果FSR涉及事后补救措施，则FSR需要定义相应的安全状态和容错区间(如果需要转移安全状态，还应定义紧急操作区间)。很多朋友不知道这些东西是否属于安全要求。
五
FSR需要被分配到系统架构中，并作为FSC的一部分，这一点我们将在后面详细介绍。
比如功能安全要求的例子：制动踏板开度必须正确反映驾驶员的制动意图(ASIL D)。至于应该用哪个传感器，如何响应意图，不是功能上的考虑。
02
什么是FSC？
功能安全概念(FSC)通常被翻译成功能安全方案或概念。个人认为功能安全方案更合理。FSC本质上是通过系统总结概念阶段的所有开发工作而形成的工作输出产品。FSC在ISO 26262的定义是模糊的，即为了满足安全目标，FSC包括安全措施(包括安全机制)。那么到底什么是安全措施呢？它和安全机制有什么区别？下面给朋友们分析一下：
一个
安全措施：事前的预防措施和事后的补救措施，比较广泛，统称为避免或控制系统故障和随机硬件故障的所有技术方案。
2
安全机制：事后补救部分只是安全措施的一部分，针对系统功能异常后，为检测、显示和控制故障而采取的措施。一般涉及到具体的技术手段，在概念阶段不需要，在系统阶段定义。
所以理论上，只要是保证相关物品的功能安全，所有在功能层面采用的解决方案都属于功能安全解决方案。一般来说，一部完整的FSC应该包括以下主要内容：
其中，安全状态主要包括：关机功能、功能退化、安全运行模式、跛行回家和其他故障安全策略。目前，失败操作策略相对较少，如冗余操作。
一旦系统违反了安全目标，安全机制必须在容错时间间隔(FTTI)将系统转移到安全状态。
下面简单说说如何确定容错时间间隔(FTTI):
一般可根据安全目标对应的代表性危害事件(一般为ASIL等级最高的危害事件)，通过对相应运行场景的定量或定性评估获得，包括历史数据、模拟计算、实际测试等。
在实际运行中，如果难以计算确定，可以根据经验预设，然后在实车运行场景中模拟出具有代表性的危险事件。最后，根据测试数据和验证标准确定假设的合理性。
对于ASIL水平较高的安全要求，理论上应进行车辆测试和确认。
最后，谈谈FSR和FSC的形式和写作工具：
首先，FSR一般直接收录在FSC，经常使用需求管理或文字工具，如Doors、Word等进行编写和管理，方便版本管理和审核。
其次，FSC内容没有统一的结构要求，只需要合理组织所需内容，形成输出结果，保证分析结果的可追溯性即可。
03
如何从SG得到FSR
与安全目标(SG)的输出，即HARA过程相比，从安全目标(SG)到功能安全要求(FSR)也需要进行安全分析，区别如下：
安全分析的对象是基于部件级别，而不是车辆或系统级别。
除了归纳分析，还可以采用演绎分析。
其中，FMEA(失效模式与影响分析)和FTA(故障树分析)是归纳演绎最具代表性的分析方法，也是功能安全开发最常用的安全分析方法。接下来，我们简单说说它们的特点和区别：
故障类型与理象分析
一种典型的归纳分析方法是从若干个别事物中获取普遍规律。
定性分析。
自下而上，从原因到结果，也就是从可能的失败原因，分析可能的有害结果。
自由贸易协定
典型演绎分析法：通过逻辑演绎从已知规律中获取新规律的方法。
定性和定量分析，多定性分析
从上到下，从结构到原因，即从有害的结果或事件，分析可能的原因。
从SG到FSR，经常使用FTA分析方法进行分析，主要是因为：
首先，FMEA一般指设计阶段的DFMEA，即设计FMEA。FMEA一般用于在产品设计或流程实际实现之前分析其安全性，找到产品的弱点，并对其进行优化和改进。因此，FMEA是指事件发生前的行为，尽可能避免危害，只包括事前预防，这与功能安全和保障机制的要求完全不同。事后补救是保障功能安全的重要措施。
其次，FTA自上而下、从结果到原因的分析方法与SG到FSR的出口方向一致，更便于操作，也更容易完整地识别故障的原因和影响。
那么我们来看看FTA的操作步骤：第一步：确定分析边界，包括分析对象、范围和抽象层次。第二步：选择被分析的故障，即顶事件，通常以违反的安全目标(SG)作为FTA的顶事件。第三步：根据顶层事件，确认故障发生的直接原因、必要原因和充分原因，建立故障树，直至分析的最低抽象层，即底层基本事件(对于FSR，一般是元器件层，如传感器、执行器、控制单元等。).第四步：根据底层基本事件，采取安全措施消除相关故障路径，制定相应的FSR。
(有兴趣的朋友可以私信我，我会考虑以后是否有必要发表安全分析文章。)
04
FSR被分配到系统架构
根据ISO 26262-3-2018的要求，FSR必须被划入FSC体系架构的重要组成部分。其主要目的是：
将不同安全目标对应的安全需求和ASIL放到架构中具体的软件或硬件组件中，然后确定不同组件开发对应的所有安全需求和最高ASIL级别需求，以便于后续系统、软件和硬件的进一步开发。
架构作为需求和具体软硬件实现之间的桥梁，是基于模型的系统工程开发(MBSE)的重要内容，可以有效改善基于文本或基于文档开发的弊端，实现模型的统一管理和维护，实现需求和测试的可追溯性和可验证性。
一般来说，系统架构一般在相关架构开发软件中开发，如Enterprise Architect、Cameo等。通过使用通用建模语言UML或SysML，作为功能安全概念开发的输入内容。但遗憾的是，目前大部分车企都没有一个完整的系统架构或者基于PowerPoint等形式的简单架构描述。这样一来，一方面无法按照架构进行安全分析，另一方面也没有办法给系统架构分配安全需求。架构是一门艺术，是软件定义汽车背景下解决系统和软件复杂性的一大利器。关于建筑的话题我以后会单独和朋友们说。写在最后：功能安全概念的阶段发展我们终于谈完了，下期继续看功能安全体系的阶段发展。审计刘清
