26262系列标准共十部分，分别从管理，流程，软硬件研发，生产和操作等方面对汽车电子产品的整个生命周期进行规范和要求。

总体来说，功能安全是指避免由系统功能性故障导致的不合理风险。它关注的是系统发生故障之后的行为，而不是系统的原有功能或性能。

所谓不合理风险(unreasonable risk)，如行车时气囊打开

因此功能安全的目的就是尽可能地通过增加安全机制（Safety Mechanism）去提高安全等级，当系统发生故障后，让系统进入可控的安全状态，实现安全目标（Safety Goal），即避免对人身造成伤害。

------------------------------------------------------------------------------------------------------------------------------------------------------------------

相关项定义（Item Definition）

在功能安全工作之前，分清楚研究对象，明确产品功能和系统边界，意思就是在系统架构图中找到所有E/E相关的组件或者功能，因为机械结构是不归26262管的。

------------------------------------------------------------------------------------------------------------------------------------------------------------------

危害事件（hazard event）：运行场景（operational situation）和功能故障（Malfunction）的组合，如夜间山路上车灯非预期熄灭

危害事件的ASIL等级由以下三个参数确定：

严重度 关注的是潜在处于风险中的每个人受到的伤害情况，包括路上的行人和车上的人。 不考虑车子的损毁情况

S0:无伤害 >> S3致命伤害

暴露度 即出现的概率，该项评估基于每辆车都配备该相关项，即不考虑车辆配置

E0:不可能 >> E4:高概率

E0无需分配ASIL等级

可控性，能够充分控制危害事件以避免特定伤害的概率，预估驾驶员 或其他处于潜在风险中的人员对该危害事件的可控性

C0：可控 >> C3：不可控

C0无需分配ASIL等级

ps，S,E,C三个值怎么来的？

交通大数据，仿真，试验等。实在不确定就按高的来。

关于这一部分还有个标准可以看看，SAE J2980-2018

每个危害事件对应至少一个安全目标，安全目标的ASIL等级来源于危害事件的ASIL等级。

安全目标是最高层级的安全要求，表述为功能目的，而非技术解决方案。

有了安全目标才有功能安全要求，以避免危害事件的不合理风险。

以上都是比较虚的部分，多理解几遍发现也就那么回事，一句话概括就是：

功能安全开发时一般由整车层面的安全目标（Safety Goal） 得到概念阶段的功能安全要求（Function safety requirements），

再分析出电子电气层面的技术安全要求（Technical safety requirements）

再概括：SG-->FSR-->系统TSR-->HW/SW SR，

到最后这一步具体的对软件、硬件的技术需求出来，软硬件工程师才能开始干些实在的事情了，例如冗余采样，内存保护什么的，就是为了实现最上层的安全目标，在车辆失控（具体某个零件失效，再具体到某个电子原器件失效）的时候有个B计划，可以挽救人的生命

FSR像是甲方对乙方的“需要实现什么功能”的要求，只需要知道大致架构；TSR像是乙方对甲方所提要求的技术解决方案，根据明确的、细化的系统架构得出

ps,根据与网上一位大神的讨论，实际项目中有些公司可能只有SR这个概念，不太扣FSR和TSR，只要能把需求描述清楚就行了，有时候由于OEM和Tier1角度和角色的差异，很难清楚界定一条需求是FSR还是TSR，有的干脆统称为功能安全需求。我理解这就像OSI七层理想模型和TCP/IP的关系一样，理想与实际应用的差异，把握精髓，把活干好就行了

一个BMS的实例：

SG-->FSR，这一步是着重于功能层面的分析，就是想想得具备什么功能才能达到这个安全目标

FSR-->TSR，这一步是照着系统方案或者系统框图来分析的；

------------------------------------------------------------------------------------------------------------------------------------------------------------------

功能安全需求的属性 - 2018版 7.4.2.4

1）运行模式（operational modes），功能安全需求所对应的系统运行模式，如system off, system active, system passive, emergency operation, safe state

2）故障容错时间间隔（fault tolerant time interval / FTTI）

3）安全状态（safe state）

operating mode, in case of a failure, of an item without an unreasonable level of risk（翻译了更看不懂了）

例如，switched-off mode

我理解的系统失效时，实施了安全机制后的系统运行状态。

------------------------------------------------------------------------------------------------------------------------------------------------------------------

功能安全概念：为实现安全目标（SG），把功能安全要求（FSR）分配给相关项的初步架构要素或外部措施的一切活动的总和。

技术安全概念：为满足功能安全要求而设计系统架构和技术安全要求（TSR）的一切活动的总和。

翻译成人话，安全概念开发的过程就是定义需求的过程。

------------------------------------------------------------------------------------------------------------------------------------------------------------------

ASIL分解

如果一个功能安全要求可以分解为两个冗余的功能安全要求，那么原来的功能安全要求的ASIL等级可以分解到这两个冗余的功能安全要求上，因为只有当两个功能安全要求同时不满足，才会导致系统的失效。

分解后的两个冗余单元之间不应发生从属失效（dependent failure），从属失效分为共因失效（common cause failure）和级联失效（cascading failure）

ASIL分解原则

ASIL分解可以在概念、系统设计、软硬件设计各个阶段进行，而且可以多次分解

一个例子：

另一个恒润的例子，

系统相关部件继承功能安全等级

加入速度传感器后分解，这一步后不同ASIL等级的软件存在于同一个ECU，需要MPU等方法保证这两块软件相互独立

加入硬件进一步分解如下，与上面那个比较相似了

------------------------------------------------------------------------------------------------------------------------------------------------------------------

系统性失效（systematic failure）和随机硬件失效（random hardware failure）

------------------------------------------------------------------------------------------------------------------------------------------------------------------

Part 6: Product development at the software level

功能安全开发在软件层面的实施

ISO26262 Part6对软件部分，提了一大堆要求，但却没有告知路径

目前来看，autosar是最符合26262要求的软件架构，从知乎Michael Sun可以看出，利用autosar工具链搞功能安全软件开发确实方便不少

功能安全如何体现在软件上，有哪些比较靠谱的研究方法。怎么来计算一个软件的SIL啊？？？ - 知乎

企业在开发符合26262标准的软件时有两种做法：

1）不论软件模块实际的ASIL等级要求如何，全部统一按照最高ASIL等级开发

2）按照软件模块实际的ASIL等级要求开发，同时提供模块间免于干扰的证据

软件模块之间相互干扰主要有时序干扰和空间干扰

对于空间干扰，常见的措施是使用内存保护单元(Memory Protection Unit , MPU)来实现软件分区。

MPU是MCU上的一个单独的硬件模块，详细了解需要查看芯片手册

内存保护涉及最底层的软件设计，需要对RAM和Flash进行合理划分。程序烧录区域NorFlash是不可写的，不用额外保护。

某ECU的Flash区划分：

Ram区划分：

软件功能安全:

架构设计时常见的措施:

异构冗余(不同的代码实现同样的功能)

故障检测

功能降级

什么叫功能安全软件， 进行充分功能安全分析，采用最新技术进行开发的高可靠性高可用性软件。安全分析包含两大类: 概念设计的安全分析， 相关失效的安全分析

概念设计的安全分析方法:FTA(针对多点失效), FMEA(针对单点失效), ETA相关失效分析: 级联失效，共因失效

采用安全分析还不能充分保证软件质量，还需要采用最新的技术进行开发。因为软件复杂度越来越高，最多的分析和测试也无法覆盖100%的场景。所以只能借助最新的技术帮助实现更高的安全性。最新的技术分为两大类，一个是最佳流程实践如ASPICE，一个是技术层面的要求如高内聚和低耦合的autosar架构，生成代码代替手写代码。