功能安全的学习笔记（二）

mqh0386

前言

最近我家宝宝生病，忙碌了两周多，心力交瘁，终于有空更新文章了。

对于功能安全（FUSA），我一直停留在只知方法不知方法论的层级，说来惭愧，一直在吃联电积累下来的FUSA老本，当然也和自己没有系统的做过FUSA有关。最近为了研究FUSA，狠下心读了几百页文档，本文仅仅是一些读后感。如有错误，请指正。

故障分类原则

我们常说单点失效，多点失效，潜伏失效。那么怎么去识别一个失效属于哪种情况。如何去计算失效率和诊断覆盖率？

故障分类，按故障层级分类如下：

Safe Fault层级: Safe Fault


Single Point Fault层级：Single Point Fault和Residual Fault

Multiple Point Fault层级：Detected Multiple Point Fault,Perceived Multiple Point Fault,Latent Multiple Point Fault

按照故障分类准则，各类故障分类如下：

Non-Safety Related: Safety Fault

违反Safety Goal且无Safety Mechanism:Single Point Fault

违反Safety Goal且有Safety Mechanism但不能被阻止的:Residual Fault

其余属于Multiple Point Fault

能被检测的Multiple Point Fault：Detected Multiple Point Fault

不能被检测但是能被察觉的Multiple Point Fault: Perceived Multiple Point Fault

其余的Multiple Point Fault情况：Latent Fault（多点故障）

失效率计算如下：

失效率 = 单点故障率+残余故障率+多点故障率+safe fault故障率

单点失效的诊断覆盖率计算如下：

单点失效的诊断覆盖率 = 1 -  （单点失效率+残余失效率）/（失效率 – safe fault失效率）

潜伏多点诊断覆盖率计算如下：

潜伏多点诊断覆盖率 =  1 – 多点潜伏失效率 / （失效率 – safe fault 失效率 – 单点故障失效率 –  残余故障失效率）

软件FEMA方法论

软件结构图

Class diagram类图：类、接口以及静态结构关系。

Object diagram对象图：一组实例及其之间的关系。

Package diagram包图：类、接口等模型元素的组织结构和层级关系。

Composite Structure diagram复合结构图：结构的内部组成以及组成之间的关系。

Component diagram组件图：描述组件和组件之间的关系。

Deployment diagram部署图：硬件的物理架构以及软件在硬件上的部署方式。

Profile diagram概型图：定义和展示UML的扩展机制

软件行为图

Use Case diagram用例图:描述系统、参与者以及他们之间的交互，注重系统的功能需求。

Activity diagram活动图:展示工作流程和动作流。类似于流程图。

State Machine diagram状态机图:不同生命周期状态下的事件或行为。

Interaction diagram交互图有如下三类：

Sequence diagram序列图:按照时间顺序展示对象之间的消息传递。

Communication diagram通信图:类似于序列图，非严格时间顺序。

Timing diagram时序图:对象之间的时间交互关系。

Interaction Overview diagram交互概览图:概括系统的主要交互流程。

软件失效定义

功能丢失

功能降级

功能随机启停

部分功能存在（性能丢失）

非预期的功能（错误时间点执行、非预期的方向、不相等的性能）

功能超限

功能延迟

软件安全机制

软件架构错误检测考虑因素

输入输出数据的范围检查


合理性检查

数据错误检测（内存保护）

外部设施监控

控制流监控（心跳包、程序流监控、Deadline检查）

软件差异化设计

软件部署

架构层级错误处理机制

静态恢复机制

适度降级

独立并行冗余

数据纠正码

软件FEMA失效分析

软件FEMA只对Severity和Detection做检测，不对Occurrence做分析。需要对ECU层级-组件层级-模块层级进行FEMA分析，最终形成FTA（故障树分析）。

故障树分析最主要的操作就是：处理好顶层事件、中间事件、底事件三者之间的关联。找到导致顶层事件发生的最小底层事件的集合。

在整个软件FEMA分析过程中，明确需求，明确造成的影响。在架构设计阶段，应做好架构级别的安全分析。在单元级别的设计阶段，应做好单元层级的安全分析。

在软件FEMA分析过程中，需要考虑对象的静态特性和动态特性，颗粒度和架构中的最小元保持一致，分析架构元素和需求、架构元素功能、接口、数据流。失效因素需要考虑硬件平台影响（硬件环境因素）、架构影响（内部环境影响）、无动态对象、变量影响（初始化、多用、限制指针的使用、隐性数据类型转换）、人为错误、没有无条件跳转、无递归等等，主要考虑系统性失效（分析单元设计内部设计、内部逻辑、判定条件、变量类型赋值、输入输出接口等）。

软件FEMA分析的内容标题

软件模块的功能逻辑（功能描述、功能条件、数据范围、运行周期等等No/Lost、More/Less、Delay/Before、Unintended、Other than、Part of）


软件模块的数据接口（接口变量、数据类型、取值范围、初始值、失效模式）

软件模块的时序及执行（周期、执行时间、执行时序、优先级、失效模式（阻塞、死锁、活锁、时间分配错误、同步失效、执行顺序错误））

软件对应的内存属性（内容失效（读取或者写入数据损坏）、访问权限（非法的读写、内存资源使用）、空间不足（分配空间不足、内存不释放、内存溢出）、地址错误（读取或者写入地址错误）、数据不一致（读取数据不一致））

软件部署（CPU核依赖（负载高低）、存储依赖（堆栈使用和访问）、底层/OS依赖（任务调度和优先级）、通信总线依赖、外设资源依赖（外设输入和配置未及时更新或者获取）、模块与模块之间的依赖）

CRC在FUSA中的应用原理

CRC校验全称循环冗余校验，一般有CRC8,CRC16,CRC32三种模式，多项式就更多了。主要用于检测或校验数据传输或者保存后可能存在出现的错误。

CRC校验的速度快、误码率低，所以常用，但是CRC校验不纠错。如果要纠错就得使用Hamming码、BCH码、Reed-Solomon码。PS：不确定的信息：IFX芯片的ECC功能就是可以检测2个Bit错误，纠正1个Bit错误，采用的好像就是硬件实现的Hamming码。

我们重新回顾一下IFX  TCxxxMCU芯片的Memory Protect Unit（MPU保护）机制，芯片会提供相应的权限保护，防止非功能安全程序访问带有安全等级的变量，一般策略是防止意外的篡改，并不防止意外的读。

那么，在MCU芯片没有MPU保护之前，内存保护怎么做呢？其实很多国际大厂就是用CRC校验做的，访问这些变量需要利用特殊的接口，不能直接访问其符号表。我之前碰到的这种变量，称之为“安全变量”，如果你在ABCD这种公司，接触到老项目，可以看看代码中还有没有这种老的机制存在。这种机制之前应用在ASIL-C等级的环境中，就ADAS而言，一般要求ASIL-B，在MPU侧开发这种功能安全机制，完全满足功能安全需求。那么使用CRC校验能满足功能安全要求的安全机制是什么呢，防止哪些错误呢？

在通信或者内存读写的过程中，一般有如下故障信息：

常见故障	安全机制
信息重复	计数器+时间戳
信息丢失/删除	计数器
信息延迟	时间戳+超时机制
通信通道阻止访问	计数器+超时机制
信息次序错误	计数器+时间戳
信息只被部分接收者收到（节点丢失）	计数器+超时机制
信息数据损坏	CRC
发送给多个接收者的信息不对称	CRC
信息插入	计数器、反馈信息、源ID、ID处理
错误寻址	DataID
伪装源发送	反馈信息、ID处理+CRC

一般情况下，如上表所示，基于上述故障和安全机制的分析，通信相关的功能采用E2E保护机制，E2E保护机制本身就带有CRC校验。

内存相关的相关故障分析如下：

常见故障	安全机制
分配空间不足	预先静态分配内存、内存监控
内存空间不释放	内存监控、定制化的内存库
写入地址错误	逻辑检测、地址信息校验
写入数据损坏	CRC校验、纠正码
写入空间溢出	CRC校验或者标志码
读取地址错误	逻辑检测、地址信息校验
读取数据损坏	CRC校验、纠正码
读取数据不一致	CRC校验、确定性调度
非法的读或写	内存访问权限隔离、共享内存划分
内存资源使用冲突	任务调度排布、时序分析

CRC校验在内存资源的错误检测中也有着很有效的作用。当然在内存保护中，一般CRC校验和特殊的Pattern联合使用，特殊Pattern的原理就是和栈区的溢出检测原理一致。
总结

FUSA在MCU中有很多硬件机制，但是在SoC侧很多机制需要软件实现。需要理解MCU侧硬件提供的功能安全机制的原理，在SoC侧用软件实现它，当然软件实现有它的局限性，但是总比没有好。

另外一方面，功能安全对编码有很多要求，总的来说，就是要求用最旧最保稳的技术开发功能安全软件，不要使用新特性，不要用动态对象。

lidenghui

功能安全学习笔记（二）前言回复

尊敬的楼主，您好！得知您因家庭事务繁忙而暂停更新文章，现在得以恢复，实属不易。对于功能安全的学习，您提到的对单点失效、多点失效及潜伏失效的识别与分类是核心要点。在故障分类原则中，按故障层级对Safe Fault和Single Point Fault进行分类是非常必要的。Safe Fault层级涉及系统安全的关键故障，需重点关注；而Single Point Fault层级则涉及单一故障点导致的系统性能下降或失效。对于失效率和诊断覆盖率的计算，是评估功能安全的重要手段。建议进一步深入研究相关文档和标准，以确保准确理解和应用。期待您后续的分享和讨论，共同提升功能安全领域的知识水平。

[内容由汽车工程师之家人工智能总结，欢迎免费使用，见贴尾]

cqzyf

功能安全学习笔记（二）续篇

针对您提到的内容，以下是专业回复：

关于功能安全中的故障分类原则，理解其重要性是确保系统安全性的基础。单点失效与多点失效的识别，对于评估系统性能及失效率至关重要。在计算失效率和诊断覆盖率时，需要考虑故障发生的概率、系统对故障的容忍度等因素。关于故障层级分类，安全故障层级需要重点关注其可能对系统安全造成的影响。单点故障层级则应分析其是否可能导致单一功能失效。对于功能安全的学习，深入了解其背后的理论框架与实际应用案例同样重要。最近因个人原因未能及时更新文章，非常感谢您的耐心等候与持续关注。希望此次笔记对您有所帮助，欢迎提出宝贵的反馈与建议，共同进步。后续关于功能安全的学习心得与感悟，我会继续分享，敬请期待。

[内容由汽车工程师之家人工智能总结，欢迎免费使用，见贴尾]

zy_wawj

功能安全学习笔记（二）续篇

针对您提到的内容，以下是专业回复：

关于功能安全中的故障分类原则，理解其重要性是确保系统安全性的基础。单点失效与多点失效的识别，对于评估系统整体稳定性至关重要。失效率及诊断覆盖率的计算是确保故障能够被准确识别和及时修复的关键步骤。对于故障层级分类，安全故障层级与单点故障层级的准确界定是实施功能安全措施的前提。对于识别和处理这些故障，我们需要深入研究并制定相应的应对策略。在实际操作中，我们不仅要关注理论层面的学习，更要注重实践应用，确保系统的可靠性和安全性。期待您的分享能够为我们带来更多关于功能安全学习的深度理解和实践应用的内容。若有任何理解上的偏差或错误，请不吝指教，共同学习进步。

[内容由汽车工程师之家人工智能总结，欢迎免费使用，见贴尾]

t007

功能安全学习笔记（二）前言及故障分类解析

因家中事务繁忙，迟来的更新，深感歉意。关于功能安全（FUSA），我深知其重要性，但之前对其理解尚浅。近期深入研究后，有了些许心得。

功能安全中的故障分类是核心基础。常见的故障类型包括单点失效、多点失效及潜伏失效。识别这些失效类型对于评估系统安全性至关重要。失效率和诊断覆盖率的计算是评估故障分类的重要手段。关于故障层级分类，需明确各类故障的定义和影响：

一、Safe Fault层级：此类故障虽发生，但不会导致系统性能降低或产生安全风险。

二、Single Point Fault层级：单点故障是系统中某一组件或功能的单一失效点。

后续将详细阐述各类故障的特点及处理方法，不当之处，敬请指正。我会持续优化学习成果，与大家共同探讨和进步。

[内容由汽车工程师之家人工智能总结，欢迎免费使用，见贴尾]

wmwlove

功能安全学习笔记（二）续篇

对于功能安全，我深知其重要性及学习过程中的难度。近期由于家中小宝贝生病，未能及时分享学习心得，深感抱歉。现在继续分享关于故障分类原则的学习内容。

故障分类是功能安全的基础。为了明确不同类型的失效模式，我们需要准确识别单点失效、多点失效及潜伏失效。在识别失效类型后，计算失效率和诊断覆盖率是关键步骤。我们根据故障层级进行如下分类：

一、Safe Fault层级：指对系统安全不会造成实际危害的故障，需要重点关注其管理和预防措施。

二、Single Point Fault层级：指单一因素导致的故障，需深入分析其原因并采取措施消除单一故障点，从而提高系统的可靠性。关于Single Point Fault层级具体的处理方法和后续研究方向我会进一步研究并分享。在后续学习过程中如有发现或理解的新观点，我会及时指出并讨论。期待与各位同行深入交流，共同进步。

[内容由汽车工程师之家人工智能总结，欢迎免费使用，见贴尾]