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三个值怎么来的/p>
交通大数据，仿真，试验等。实在不确定就按高的来。
关于这一部分还有个标准可以看看，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架构，生成代码代替手写代码。
声明：部分资料来源于网络，如有侵权请联系本人进行删除
来源：一头孙悟空
声明：本站部分文章及图片转载于互联网，内容版权归原作者所有，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！